Caracterização da QoS na Implantação de Soluções VoIP

Caracterização da QoS na implantação de soluções VoIP Karine Belens Pessoa, Joberto Sérgio Barbosa Martins, Sérgio de Figueiredo Brito, Marcos Portnoi, Rafael Gonçalves Bezerra de Araújo

Abstract: There are a lot of reasons to send voice over IP, but this protocol has some limitations. All its structure aims at simplicity and, as consequence, it possesses limitations that hinder that sensible medias to the delay, as for example the voice, can be carried with quality. Therefore, it becomes necessary the implantation of strategies and mechanisms of QoS that guarantee the quality of a VoIP application (Voice Over IP). The intention of this work is to define parameters of traffic that can be configured, of adjusted form, with the objective to guarantee the attendance of the criteria of Quality of Service (QoS) demanded by a VoIP application, twirling in a IP Diffserv network. To reach the objectives, it considers a model of simulation for, through the tool of simulation NS-2, to get a set of results and for, finally, from the analysis of the results, to suggest specifications of parameters that can be applied of practical form in corporative nets, with the objective to contribute for the increase of the quality of the same ones.

Resumo: Existem grandes motivações para trafegar voz em redes IP, entretanto este protocolo possui algumas limitações. Toda a sua estrutura visa a simplicidade e, como consequência, possui limitações que impedem que mídias sensíveis ao atraso, como por exemplo a voz, possam ser transportadas com qualidade. Para tanto, torna-se necessário a implantação de estratégias e mecanismos de QoS que garantam a qualidade de uma aplicação VoIP (Voice Over IP). O propósito deste trabalho é definir parâmetros de tráfego que possam ser configurados, de forma adequada, com o objetivo de garantir o atendimento dos critérios de Qualidade de Serviço (QoS) exigidos por uma aplicação VoIP, rodando em uma rede IP Diffserv. Para atingir os objetivos, propõe-se um modelo de simulação para, através da ferramenta de simulação NS- 2, obter um conjunto de resultados e para, finalmente, a partir da análise dos resultados, sugerir especificações de parâmetros que possam ser aplicados de forma prática em redes corporativas, com o objetivo de contribuir para o aumento da qualidade das mesmas.

1. Introdução A telefonia é uma tecnologia antiga e eficiente. É também uma forma de comunicação que atinge grande parte da humanidade. A rede de comutação telefônica, desta forma, possui uma base instalada muito estável e confiável. Entretanto, é inegável que as redes de comutação de pacotes, inicialmente projetadas para a transmissão de dados, vêm aumentando o número de usuários de forma geométrica. Assim, fica evidenciada a importância de Internet, cuja tecnologia se baseia no protocolo IP (Internet Protocol). Em função do aumento da capacidade de processamento dos sistemas computacionais e das taxas de transmissão dos enlaces, cada vez mais, se utiliza a estrutura de uma rede de computadores para transmitir mídias contínuas, como voz e vídeo. O uso da tecnologia de voz sobre redes IP é motivada por alguns aspectos, dentre os quais pode-se citar: economia no custo das chamadas de longa distância, interurbanas e internacionais, aumento da produtividade em função da integração de aplicações de voz e dados e o fato da instalação da infra-estrutura ser feita de maneira natural, uma vez que, normalmente, as empresas já possuem uma rede de dados IP, o que também contribui para uma redução do investimento inicial. Apesar da simplicidade e popularidade, redes IP apresentam problemas quando se trata de transmitir mídias sensíveis ao atraso como a voz. O protocolo IP, instalado no núcleo da rede, presta um serviço sem conexão, o que implica na inexistência de algumas garantias. Não há garantia, por exemplo, que haja um atraso constante, o que pode tornar uma aplicação de voz em tempo real, como por exemplo uma conversa telefônica, um serviço de baixa qualidade com a voz entrecortada e muitas vezes ininteligível. Este trabalho tem o objetivo de identificar e sugerir parametrizações para obtenção da qualidade de serviço para aplicações VoIP executadas em uma rede DiffServ. Neste sentido, será apresentada

1

uma análise da transmissão de voz sobre o IP e uma proposta de simulação utilizando a ferramenta de simulação NS. Através de simulações, indicaremos configurações e parametrizações que possam ser aplicadas de forma prática em redes corporativas, com o objetivo de contribuir para o aumento da qualidade das mesmas na utilização da tecnologia VoIP. Por fim, serão apresentadas as conclusões deste trabalho.

2. Uma análise da transmissão de voz sobre o IP A tecnologia VoIP é implementada, simplistamente, da seguinte forma: transforma-se a voz em sinal digital e encapsula os dados em pacotes IP. Esta simplicidade permite a transmissão de dados e voz dentro de uma mesma rede, fazendo com que aplicações de voz em tempo real sobre o protocolo IP se tornem uma realidade em redes corporativas [Goode, 2002]. Numa rede de computadores, a qualidade de serviço (QoS) consiste no atendimento de requisitos solicitados por aplicações. Assim sendo, o atendimento dos requisitos de QoS por uma rede implica em atuar nos equipamentos envolvidos na comunicação, visando o controle dos parâmetros de QoS como, por exemplo, jitter, taxa de perdas e atraso. Muitos fatores determinam a qualidade da voz, incluindo a escolha do codec, controle de eco, perda do pacote, atraso, variação do atraso (jitter) e o projeto da rede. A perda do pacote provoca falhas na voz. Alguns algoritmos de codec podem corrigir algumas perdas de pacotes de voz. Caracteristicamente, apenas um único pacote pode ser perdido durante um período curto para que a correção do codec seja eficaz [Goode, 2002]. Se o atraso fim-a-fim se tornar muito longo, a conversa começa a perder a qualidade. Um buffer no aparelho receptor sempre equilibra o jitter. Se a variação do atraso excede o tamanho do buffer, haverá uma perda de pacotes em qualquer ponto da linha de transmissão, prejudicando a qualidade da mensagem recebida. Segundo a recomendação G.114 do ITU-T, o percentual de perdas não deve ultrapassar 10 %, o atraso máximo aceitável é de 200 ms e o jitter máximo suportável é de 40 ms. Em função da disseminação da utilização da infra-estrutura de Internet para novos serviços, a pressão para a implementação de garantias de QoS dentro do próprio ambiente IP levou ao desenvolvimento de tecnologias que possam ajustar parâmetros para obtenção de QoS. Destas propostas podemos citar o IntServ [White,1997] e o DiffServ [Blake,1998]. O DiffServ efetua o encaminhamento de tráfegos agregado de forma não orientada a conexão, estabelecendo classes de serviço onde existe tratamento de prioridade entre as mesmas. A obtenção de QoS é resultado de uma estratégia de medição de tráfego e marcação de pacotes que funciona através de um mecanismo de classificação e suavização de tráfego nos nodos da fronteira. No núcleo do domínio existem esquemas de encaminhamento de tráfego eficientes para que sejam atendidos os critérios de QoS. O nodo da fronteira é responsável pela associação do tráfego do usuário a uma classificação pré-estabelecida. Uma vez classificado, o tráfego é encaminhado pelo núcleo em função de uma política conhecida como PHB (Per Hop Behavior). A proposta DiffServ prevê a possibilidade de efetuar um descarte seletivo de pacotes com o objetivo de minimizar a possibilidade de congestionamento em uma rede IP. Uma possibilidade de algoritmo para esta atividade é o RED/RIO [Floyd,1993]. Prevê, também, um mecanismo de escalonamento de filas com o objetivo de escolher pacotes para transmissão, respeitando a prioridade de cada fila. Um algoritmo que pode ser usado para esta função é o WRR (Weighted Round Robin).

3. Proposta de Trabalho A proposta de simulação consiste em um modelo de rede DiffServ que executa uma aplicação VoIP. A topologia está apresentada na Figura 1. A política de PHB é o AF (Assured Fowarding) implementado em três etapas: suavização do tráfego nos nodos de fronteira através do mecanismo de token bucket, gerenciamento das filas com o objetivo de evitar congestionamento através do algoritmo RED (Random Early Detection) e escolha dos pacotes que serão efetivamente enviados através do algoritmo de prioridade WRR. A ferramenta de simulação em uso neste trabalho é o NS (Network Simulator) [NS, 2002], um simulador de eventos discretos desenvolvido em C++.

2

Tráfego de Voz Input 0 Nó 0

. . .

Gateaway IP

10 MB

Edge0 Roteador de Fronteira de Entrada Nó 2

Core0 Roteador do Núcleo Nó 3

RED + WRR

1 MB

Token Bucket + RED + WRR

10 MB

RED + WRR dsred/core

HUB

1 MB

Token Bucket + RED + WRR dsred/edge

10 MB Tráfego FTP Input 1 Nó 1

Edge1 Roteador de Fronteira de Saída Nó 4 HUB

Nó 5 Sink0

Figura 1. Topologia da rede simulada.

Os parâmetros referentes à estratégia DiffServ configurados no modelo estão vinculados ao mecanismo de suavização de tráfego token bucket, ao algoritmo de controle de congestionamento RED/RIO e ao algoritmo de prioridade WRR. A Figura 2 mostra os parâmetros de configuração dos roteadores. Condicionamento do tráfego Bucket

Mecanismo de Controle de Congestionamento

Size ( CBS)

Filas nas Interfaces de Entrada

Token Generation ( CIR)

Voz

FTP

Há fichas ?

Sim

Implementação das Filas de Voz e FTP

Implementação das Filas IN e OUT de Voz e FTP Pacote IN

RIO

Mecanismo de Scheduling

WRR Fila na Interface de Saída

Não Pacote OUT

Peso das filas

Token Bucket Numqueues, Numprec, MeanPktSize ,Min_thresh, Max_thresh, maxdropprob

Figura 2. Parâmetros da estratégia DiffServ .

As fontes geradoras do tráfego de voz foram configuradas como fontes exponenciais ON-OFF. Quando as fontes ON-OFF estão no estado de atividade “ON” é gerado um tráfego de voz a um pico de 64 kbps (correspondente ao padrão PCM). Os períodos de atividade são determinados por uma variável aleatória com distribuição exponencial de média 400 ms. Os períodos de silêncio OFF também são distribuídos exponencialmente por uma variável de 600 ms [Rezende e Ziviani, 1999]. O tamanho dos pacotes também é um parâmetro configurável. O modelo de simulação DiffServ proposto consiste em cinco nós interligados através de enlaces de 10 Mbit/s (nós de fronteira) e 1 Mbit/s (nós do núcleo). Os nós zero e 1 representam os geradores do tráfego de voz e FTP respectivamente. Os geradores de tráfego encaminham seus pacotes através de links de 10 Mbit/s ao nó 2 ou edge0 que representa o roteador de fronteira de entrada. O mesmo recebe os pacotes e, após a associação do tráfego a uma classificação pré estabelecida, encaminha os pacotes ao roteador do núcleo ou core (nó 3), utilizando o PHB/AF através de um enlace de 1 Mbit/s. O core, por sua vez, encaminha os pacotes para o roteador de fronteira de saída ou edge1 (nó 4) utilizando a política PHB/AF e, por fim, os pacotes são enviados ao nó receptor (nó 5 ) pelo edge1 através de um enlace de 10 Mbit/s.

4. Resultados Nesta seção, serão apresentados os resultados das simulações. A partir da análise destes resultados, serão definidos parâmetros de configuração de roteadores necessários para atender a níveis aceitáveis de determinados indicadores de QoS para o tráfego de voz, como por exemplo atraso, jitter e taxa de perdas, com o objetivo de garantir um bom desempenho das aplicações VoIP.

3

 Percentual de Perdas Do ponto de vista deste trabalho, entende-se inicialmente que o percentual de perdas na operação de roteadores pode vir a ser influenciado pelo seguinte conjunto de parâmetros de configuração mostrados na figura 2 : parâmetro de operação do algoritmo de escalonamento WRR identificado na figura 2 como o “peso” da fila; tamanho do pacote FTP; parâmetros do algoritmo de controle de congestionamento RED identificados na figura 2 como “min_thresh” e “max_thresh”; parâmetros do token bucket identificados na figura 2 como CIR e CBS.

 Parâmetro do algoritmo WRR O quadro 1 apresenta os resultados das simulações, obtidos para análise do percentual de perdas em relação ao parâmetro peso do algoritmo WRR. Quadro 1. Peso Voz, FTP (WRR)

Resultados perda x peso

9,1

8,2

6,4

5,5

4,6

25,98

54,64

76,84

77,17

80,19

24,57

55,65

73,15

77,26

81,53

26,17

51,08

73,77

76,91

83,47

25,28

54,42

73,72

75,33

82,44

25,15

54,94

73,76

76,09

81,73

A primeira constatação óbvia dos resultados da simulação é que as perdas associadas aos canais de voz são altas (entre 25,43 e 81,87 %), mesmo com uma priorização máxima para a fila VoIP. Isto demonstra que a simples priorização no algoritmo de escalonamento não garante uma operação tal que resulte em baixas perdas para os canais de voz. A explicação advém dos seguintes fatos: a priorização 9:1 (VoIP:FTP) efetivamente garante que as filas VoIP serão descarregadas 9 entre 10 vezes e como os tamanhos dos pacotes são diferentes (VoIP = 80 bytes e FTP = 1500 bytes), a banda líquida associada às filas VoIP acaba sendo inferior a 90 % da capacidade do enlace. Os próximos resultados mostrarão configurações que viabilizarão a priorização efetiva dos canais de voz no WRR, levando a uma perda dentro dos limites recomendados pelo ITU-T.

 Tamanho do pacote FTP O quadro 2 apresenta os resultados das simulações, obtidos para análise do percentual de perdas em relação tamanho do pacote FTP. Quadro 2.

Resultados perdas x tamanho do pacote FTP

Parâmetros do WRR: 6: 4 Tam pacote FTP

100

110

120

130

6,53

8,08

9,10

11,82

4,4

9,50

9,26

12,26

5,46

10,00

10,00

13,67

7,47

9,00

12,23

16,82

6,18

7,92

12,46

11,34

Em função do mecanismo de funcionamento do algoritmo WRR, quanto maior o tamanho do pacote FTP, maior será a largura de banda alocada para este tipo de tráfego, o que fará com que o tráfego de voz seja prejudicado na disputa pelo acesso a largura de banda compartilhada, ou seja, quanto maior o tamanho do pacote FTP, maior será o percentual de perdas. Os resultados mostram que pacotes FTP muito grandes comprometem o mecanismo de priorização implementado pelo algoritmo WRR, ou seja, mesmo configurando uma relação de prioridade 9:1 para os tráfegos de voz e FTP, não se consegue uma priorização efetiva do tráfego de voz, comprometendo o percentual de perdas. Utilizando uma priorização 9:1, o tamanho máximo de pacote permitido foi de 900 bytes. Quando a priorização utilizada foi de 6:4, o tamanho máximo permitido foi de 110 bytes. A partir destes valores de tamanho de pacote FTP, observa-se o comprometimento do algoritmo WRR. O tamanho do pacote de voz considerado foi de 80 bytes.

4

 Parâmetros do algoritmo RED O quadro 3 apresenta os resultados das simulações, obtidos para análise do percentual de perdas em relação aos parâmetros min_thresh e max_thresh. Quadro 3. Min_thresh, Max_thresh

Resultados perdas x min_thresh e max_thresh

15,30/10,20

100,200/50,100

16,00

11,03

12,08 16,03

500,1000/250,500

3000,6000/1500,3000

7,60

9,47

12,08

9,71

8,16

9,46

10,74

7,28

14,31

9,35

7,45

8,86

12,29

9,16

10,75

8,79

Os parâmetros do RED definirão o descarte. Quanto maior o parâmetro “MaxP”, mais agressivo será o algoritmo de descarte e quanto maior o “max_thresh” e “min_thresh”, menor a probabilidade de descarte de pacotes, uma vez que os pacotes terão buffer suficiente para serem enfileirados e consequentemente encaminhados, no lugar de descartados. Valores altos para estes parâmetros garantem que o descarte de pacotes seja forçosamente atenuado pela existência de uma fila muito grande, o que reduz o percentual de perdas.

 Parâmetros do Token Bucket O quadro 4 apresenta os resultados das simulações, obtidos para análise do percentual de perdas em relação aos parâmetros do token bucket. Quadro 4.

Resultados perdas x parâmetros do token bucket

CIR e CBS de Voz

768,80

100,20

1,10

9,47

11,52

12,15

8,16

12,03

10,00

7,28

11,33

17,12

8,86

10,53

16,30

8,79

10,83

15,42

Quanto mais restritos os parâmetros do token bucket, isto é, menores, maior o número de pacotes classificados como “out” e sabe-se que os pacotes out têm maior prioridade de descarte que os pacotes “in”, o que contribui para um aumento do percentual de perdas.

 Atraso Do ponto de vista deste trabalho, entende-se que o atraso na operação de roteadores pode vir a ser influenciado pelos parâmetros, parâmetros do algoritmo RED identificados na figura 2 como “min_thresh” e “max_thresh”. O quadro 5 apresenta os resultados das simulações, obtidos para análise do atraso (em ms) em relação aos parâmetros min_thresh e max_thresh. Quadro 5. Min_thresh, Max_thresh

15,30/10,20

Resultados atraso x min_thresh, max_thresh 100,200/50,100

500,1000/250,500

3000,6000/1500,3000

92,43

101,74

109,01

107,90

86,80

110,10

117,35

120,00

87,15

103,48

102,72

105,14

92,68

88,00

103,40

103,06

94,81

85,10

101,26

102,74

Parte do atraso é decorrente da velocidade do link, dos tempos de propagação de cada link, da velocidade dos geradores de tráfego e do número de fontes geradoras de tráfego. O atraso adicional é decorrente do tempo em fila que é influenciado pela configuração dos parâmetros min_thresh e max_thresh e pela banda disponível para o tráfego que pode ser controlada pelos parâmetros do token bucket. Quanto maior o min_thresh e max_thresh, maior será o número de pacotes enfileirados ao invés de descartados e consequentemente maior será o atraso.

5

 Jitter O jitter é influenciado pelos parâmetros “min_thresh” e “max_thresh”. Quanto maior o “min_thresh” e o “max_thresh”, menor será o jitter, pois maiores serão os buffers que compensarão o jitter. O jitter também é decorrente de uma variação do tamanho dos buffers, por isso para que ele seja reduzido, o RED deve ser configurado com limiares do tamanho médio da fila não muito distantes para evitar uma grande variação. O quadro 6 apresenta os resultados das simulações, obtidos para análise do jitter (em ms) em relação aos parâmetros min_thresh e max_thresh. Pode- se observar que a configuração de valores altos para o “min_thresh” e o “max_thresh” permitiu chegar a um jitter médio da simulação por fonte de voz inferior a 40 mseg. Quadro 6. Min_thresh, Max_thresh

15,30/10,20

Resultados jitter x min_thresh, max_thresh 100,200/50,100

500,1000/250,500

3000,6000/1500,3000

45

40

25

25

47

42

37

27

35

35

23

35

47

38

20

14

35

37

33

16

5. Conclusões É claro que todos os aspectos de uma rede não podem ser simultaneamente melhorados. Deve-se balancear o projeto da rede para otimizar a vazão (throughput) dos dados, atraso total, jitter e perda. Os valores dos parâmetros a serem escolhidos devem conciliar baixo atraso, baixo percentual de perdas, baixo jitter e, se possível, uma boa utilização de banda. Conciliar estes parâmetros de QoS não é uma tarefa muito simples, uma vez que, em algumas situações, eles se tornam conflitantes, exigindo uma boa dose de bom senso para priorizar algum deles em detrimento de outros e uma boa dose de esforço para, em cada modelo de rede, conseguir determinar os valores ideais dos parâmetros de tráfego. Pode-se citar como exemplo o jitter e o atraso. Para se ter um baixo jitter, deve-se configurar o “min_thresh” e “max_thresh” com valores altos, entretanto os altos valores dos mesmos contribuem para aumentar o atraso. Por outro lado, é melhor um alto atraso que um alto jitter, uma vez que o jitter já é um componente do atraso e portanto a tolerância a ele é realmente muito pequena. Por motivos já comentados neste documento, o tráfego de voz deve ser priorizado. Por outro lado, deve-se tentar restringir, o mínimo possível, o tráfego FTP, afinal este tipo de tráfego também precisará dos recursos da rede para executar de forma eficiente. Ele só não é prioritário. Consequentemente, deve-se buscar a configuração dos parâmetros do esquema Diffserv que priorize o tráfego de voz através do alcance dos limites dos valores dos parâmetros de QoS recomendados pelo ITU-T. Uma vez alcançado estes limites, não há mais necessidade de restrição do tráfego FTP. Vale ressaltar que os parâmetros de simulação afetam as estatísticas do tráfego até um ponto que se pode chamar de ponto eficiência máxima dos parâmetros. O efeito que os parâmetros possuem sobre as estatísticas da simulação são limitados, isto é, existe um valor limite ou de eficiência máxima. O atraso, por exemplo, não seria infinito na simulação. Ele não é determinado apenas pelos parâmetros do RED, uma vez que os mesmos afetam o atraso dos pacotes, mas dependem do tamanho médio da fila que é determinada pelas taxas de chegada (taxa de geração das fontes) e as taxas de serviço (velocidade dos links), logo, em tese, não adianta alterar os parâmetros “max_thresh” e “min_thresh” além do valor da fila média calculado, pois chegou-se ao valor limite ou de eficiência máxima. Este fato pode ser observado no quadro 5, onde é mostrado que qualquer valor acima de 500, 1000, referentes ao “min_thresh” e “max_thresh” do tráfego de voz, não afeta, de forma significativa, o valor do atraso. Este fato também foi observado com relação aos parâmetros do token bucket. Causa pouco impacto sobre os parâmetros de QoS, aumentar o CIR, além da velocidade de geração do tráfego da fonte, uma vez que não haverá sincronia entre a geração e o consumo dos tokens. A conseqüência será que alguns tokens serão gerados, mas não consumidos. A partir das simulações executadas, constatou-se que deve-se configurar os valores de “min_thresh” e “max_thresh” do tráfego de voz altos o suficiente para garantir uma boa utilização, um valor de atraso aceitável, um baixo jitter e um baixo percentual de perdas (sugere-se 100 e 200; 50 e 100 bytes para

6

as filas IN e OUT respectivamente). A prioridade máxima de descarte do tráfego de voz deve ser configurada com baixos valores, a fim de atenuar o percentual de perdas (sugere-se 0.01 e 0.05 para as filas IN e OUT respectivamente), O CIR e o CBS do tráfego de voz devem ser configurados com valores que representem, respectivamente, a taxa de geração das fontes e o tamanho da rajada do tráfego. Neste estudo, estes parâmetros foram configurados com os valores de 1024 kbps (foram usadas 16 fontes a 64 kbps) e 80 bytes, o que equivale ao tamanho de um pacote do tráfego de voz. Estes valores permitem que o descarte de pacotes de voz seja atenuado através de liberação de banda para este tipo de tráfego. Os parâmetros do token bucket, do RED e o tamanho do pacote devem ser configurados de forma a restringir o tráfego FTP e liberar recursos para o tráfego de voz, uma vez que o tráfego FTP não tem grandes exigências no que diz respeito aos parâmetros de QoS e, por rodar sobre o TCP, tende a tomar toda a banda existente, prejudicando o tráfego de voz concorrente. Durante as simulações, pôde-se verificar que o gráfico do tráfego entre edge0 e core0 é parecido com o gráfico do tráfego entre input1 e edge0(FTP), o que significa que o tráfego FTP procura se adaptar ao estado do enlace. Dessa forma, deve-se configurar a prioridade do tráfego de voz com um valor maior que a do tráfego FTP, isto pode ser feito através da configuração do parâmetro peso do algoritmo WRR (sugere-se 6:4). Assim como deve-se restringir o tráfego FTP através da configuração de baixos valores para o “min_thresh”, “max_thresh” (5 e 10; 3 e 6 bytes), CIR e CBS (110 Kbps e 512 bytes respectivamente) e um valor alto para a probabilidade máxima de descarte (0.10 e 0.20). O tamanho do pacote FTP também deve ser restrito, não podendo ser muito maior que o do tráfego VoIP para que o parâmetro do algoritmo WRR possa fazer efeito no que diz respeito a prioridade de acesso a recursos, como por exemplo, largura de banda. Por exemplo, sugere-se 80 bytes para o pacote de voz e 110 bytes para o pacote FTP. Uns grandes números de simulações foram executados com o objetivo de determinar os valores ótimos dos vários parâmetros de tráfego. No entanto, as configurações dos valores dos parâmetros dependem da caracterização da carga da rede que influencia diretamente no tamanho da fila. Não existem muitas regras – as prioridades e requisitos de uma dada situação irão ditar os compromissos apropriados.

6. Referências [Blake,1998] BLAKE, S.; BLACK, D.; CARLSON, M.; DAVIES, E.; WANG, Z. e WEISS, W. – An Architecture for Differentiated Services. Internet RFC, Dec. 1998, rfc2475. [Floyd,1993] FLOYD, Sally e JACOBSON, Van – Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, vol 1, no 4, agosto 1993.

[Goode, 2002] GOODE, Bur. – Voice Over Internet Protocol(VOIP). Proceedings of the IEEE, vol 90, no 9, setembro 2002. [Keagy,2000] KEAGY, Scott. Integrating Voice and Data Networks. Cisco Press, 2000 [NS, 2002] The Network Simulator – ns-2 [On line]. Disponível na internet via URL: http://www.isi.edu/nsnam. Arquivo capturado em julho/2002. [Rezende e Ziviani, 1999] REZENDE, J. F; ZIVIANI Artur. Tráfego de Voz em um ambiente de dIferenciação de serviços na Internet. Rio de Janeiro, 1999.Disponível em http://www.gta.ufrj.br. [White,1997] WHITE, Paul P. – Rsvp and Integrated Services in the Internet: A Tutorial. IEEE Communication Magazine, maio 1997

7