Vous êtes sur la page 1sur 68

CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO CEARÁ

ESPECIALIZAÇÃO EM TELEMÁTICA COM ÊNFASE EM REDES

IMPACTO DE REDE PRIVADA VIRTUAL EM VOZ SOBRE IP

ANTONIO LUIZ CAMÊLO CHAVES

Fortaleza, 2006.

ii

ANTONIO LUIZ CAMÊLO CHAVES

IMPACTO DE REDE PRIVADA VIRTUAL EM VOZ SOBRE IP

Monografia apresentada ao Centro Federal de Educação Tecnológica do Ceará – CEFETCE para obtenção do Título de "Especialista em Telemática com Ênfase em Redes".

Orientador: Prof. Valdson Alencar, M.Sc.

Fortaleza, 2006.

iii

ANTONIO LUIZ CAMÊLO CHAVES

IMPACTO DE REDE PRIVADA VIRTUAL EM VOZ SOBRE IP

Esta Monografia foi julgada adequada para obtenção do Título de "Especialista em Telemática com Ênfase em Redes", aprovada em sua forma final pela Coordenação de Telemática do Centro Federal de Educação Tecnológica do Ceará- CEFETCE.

Prof. Marcus Antonio Almeida Rodrigues, M.Sc.

Banca Examinadora:

Coordenador do Curso

Prof. Valdson Alencar, M.Sc. Orientador

Prof. Wendell Rodrigues, M.Sc.

Prof. André Luiz, M.Sc.

iv

Dedico

este

trabalho

DEDICATÓRIA

à

minha

família,

em

especial

aos

meus

pais,

responsáveis por uma filosofia de vida que me fez chegar ao nível atual de

conhecimento e tão bem me mostraram a importância do mesmo.

v

AGRADECIMENTOS

Ao Prof. Valdson Alencar pela orientação

A minha esposa, Liduina, pelo apoio e compreensão;

A DARTE, que gentilmente cedeu o ambiente para os testes;

Ao companheiro de trabalho Gardel, pelo apoio profissional;

A todos que de alguma forma contribuíram para a realização deste trabalho.

vi

SUMÁRIO

Lista de Figuras

viii

Lista de Tabelas

ix

Lista de Abreviaturas e Siglas

x

Resumo

xii

Abstract

xiii

1. CAPÍTULO 1 – INTRODUÇÃO

1

1.1 OBJETIVOS

2

 

1.1.1 Geral

2

1.1.2 Específicos

2

1.2 JUSTIFICATIVAS

3

1.3 RESULTADOS ESPERADOS

3

1.4 ESTRUTURA DO TRABALHO

4

2. CAPÍTULO 2 - VOZ SOBRE IP (VOIP)

5

2.1 CODIFICAÇÃO DE VOZ

6

2.2 PROBLEMAS COM QUALIDADE DA VOZ

7

 

2.2.1 Atraso (ou Latência)

7

2.2.2 Variação do atraso (jitter)

8

2.2.3 Perda de pacotes

9

2.2.4 Largura de Banda (Bandwidth)

9

2.3

MÉTODOS DE TESTE DE QUALIDADE VOZ

11

2.3.1 E-Model

12

2.3.2 PESQ

13

2.4

CONCLUSÃO

13

3. CAPÍTULO 3 – REDE VIRTUAL PRIVADA (VPN)

14

3.1 VISÃO GERAL

14

3.2 TUNELAMENTO

15

3.3 PROTOCOLOS DE TUNELAMENTO

16

 

3.3.1 PPTP (Point-to-Point Tunneling Protocol)

17

3.3.2 L2TP (Layer 2 Tunneling Protocol)

18

3.3.3 IPSec (Internet Protocol Security)

19

3.3.4 SSL/TLS (Secure Socket Layer/ Transport Layer Security)

21

3.4

CONCLUSÃO

22

4. CAPÍTULO 4 – VPN EM LINUX

23

4.1 VISÃO GERAL

23

4.2 SOLUÇÕES

24

 

4.2.1 Poptop

25

4.2.2 S/WAN

25

4.2.3 OpenVPN

26

4.3

DESEMPENHO

27

vii

5. CAPÍTULO 5 – EXPERIMENTOS

29

5.1 OBJETIVO

29

5.2 AMBIENTE DE TESTES

29

5.3 SOFTWARES UTILIZADOS

32

5.4 PREPARAÇÃO DA VPN

35

5.4.1 Instalação do OpenVPN

35

5.4.2 Preparação da infra-estrutura de chave pública

36

5.4.3 Arquivos de configuração do Servidor e do Cliente

38

5.5

CONFIGURAÇÃO DO IXCHARIOT

40

6. CAPÍTULO 6 – RESULTADOS

44

6.1 RESULTADOS

44

6.2 CONCLUSÕES

48

6.3 SUGESTÕES PARA TRABALHOS FUTUROS

50

7. REFERÊNCIAS BIBLIOGRÁFICAS

51

8. BIBLIOGRAFIA

54

viii

LISTA DE FIGURAS

Figura 1 – Lógica de VPN

14

Figura 2 – Tunelamento

15

Figura 3 – Estrutura de um pacote PPTP

17

Figura 4 – Estrutura de um pacote L2TP

18

Figura 5 – Estrutura de um pacote L2TP criptografado com IPSec

19

Figura 6 – Estrutura do pacote IPSec em modo túnel

20

Figura 7 – Estrutura do pacote IPSec em modo transporte

20

Figura 8 - Pilha do protocolo SSL

21

Figura 9 – Exemplo de VPN com Linux

24

Figura 10 – Camadas do OpenVPN

27

Figura 11 – Ambiente de Testes

29

Figura 12 - Tráfego do Linux 1 antes dos testes

31

Figura 13 - Tráfego do Linux 2 antes dos testes

31

Figura 14 – Ambiente do IxChariot

33

Figura 15 – Ambiente de Testes após configurada a VPN

40

Figura 16 - Tela de configuração de um par de teste para VoIP

41

Figura 17 – Par de teste VoIP no IxChariot Console

42

Figura 18 - Gráfico do MOS no teste sem VPN

45

Figura 19 - Gráfico do MOS no teste com VPN

45

Figura 20 - Gráfico do MOS com o resultado dos dois testes

46

Figura 21 – Gráfico do atraso fixo de rede

47

ix

LISTA DE TABELAS

Tabela 1 – Principais recomendações ITU-T para codificação de voz (codec)

6

Tabela 2 - Efeito de algumas codificações de voz na largura de banda

10

Tabela 3 – Largura de banda incluindo o overhead da camada de enlace

10

Tabela 4 – Escala da qualidade e do esforço para entendimento (MOS e MOS-LE)11

Tabela 5 - Relação entre o fator R e a satisfação do usuário

12

Tabela 6 - Configuração dos computadores

30

Tabela 7 - Endereçamento IP do ambiente de testes

40

Tabela 8 - Resultados do teste de VoIP

44

Tabela 9 – Resultados do atraso fixo de rede

46

Tabela 10 – Resultados da perda de dados

47

x

LISTA DE ABREVIATURAS E SIGLAS

AH – Authentication Header

ACELP - Algebraic-Code-Excited Linear-Prediction

ADPCM - Adaptive Differential Pulse Code Modulation

ATM – Asynchronous Transfer Mode

CHAP – Challenge Handshake Authentication Protocol

CIR – Commited Information Rate

CS-ACELP - Conjugate-Structure Algebraic-Code-Excited Linear-Prediction

ESP – Encapsulating Security Payload

GRE – Generic Routing Encapsulation

IBM – International Business Machines

IETF – Internet Engineering Task Force

IP – Internet Protocol

IPSec – Internet Protocol Security

IPX – Internetwork Packet Exchange

ITU-T - Telecommunication Standardization Sector of International

Telecommunication Union

KLIPS – Kernel IP Security

L2F – Layer 2 Forwarding

L2TP – Layer Two Tunneling Protocol

LDCELP - Low-Delay Code Excited Linear Prediction

MLP – Multilink Point-to-Point Protocol

MOS – Mean Opinion Score

xi

MP-MLQ - Multipulse Maximum Likelihood Quantization

MPPC – Microsoft Point-to-Point Compression Protocol

MPPE – Microsoft Point-to-point Encryption

MRTG – Multi Router Traffic Grapher

MS-CHAP – Microsoft Challenge Handshake Authentication Protocol

NetBEUI – NetBIOS Extended User Interface

PAP – Authentication Protocol

PCM - Pulse Code Modulation

PESQ – Perceptual Evaluation of Speech Quality

PPP – Point-to-Point Protocol

PPTP – Point-to-Point Tunneling Protocol

PSTN – Public Switched Telephone Network

RFC – Request For Comment

RTP – Real-Time Protocol

SA – Security Association

SNMP – Simple Network Management Protocol

SSL/TLS – Secure Socket Layer/Transport Layer Security

TCP – Transmission Control Protocol

UDP – User Datagram Protocol

VoIP – Voice over IP

VPN – Virtual Private Network

VPNC – Virtual Private Network Consortium

xii

RESUMO

Redução de custos é um ponto-chave nas empresas. A tecnologia de Voz sobre IP (VoIP) tem se tornado quase obrigatória pela redução de custos com ligações interurbanas e internacionais. O uso de Rede Virtual Privada (Virtual Private Network – VPN) para interligar matriz e filiais também tem crescido e um dos motivos é a redução de custos. A adoção de soluções gratuitas de software como o Linux segue a mesma linha de redução de custos. A implementação de Voz sobre IP nas empresas costuma aproveitar a infra-estrutura já existente, inclusive de VPN, o que pode degradar a qualidade do serviço. Este trabalho se propõe a analisar o impacto que a Voz sobre IP sofre quando implementada usando uma solução de Rede Privada Virtual. Será submetido tráfego de VoIP em duas situações: sem VPN e com VPN. O resultado será analisado com base na recomendação G.107 (E-Model) do ITU-T (International Telecommunication Union), que descreve um método objetivo de análise de parâmetros em uma transmissão que afetam a qualidade da comunicação.

xiii

ABSTRACT

Cost reduction is a key-point in the companies. The Voice over IP (VoIP) technology has been almost obligated, because of cost reduction in interurban and international calls. The use of Virtual Private Network – VPN to establish connections with branch offices also has grown and one of the reasons is the cost reduction. The adoption of free software as Linux follows the same idea of cost reductions. The Voice over IP implementation in the companies is used to being over actual infra-structure, including VPN, which can degree the service quality. This paper will analyze the impact that a Voice over IP suffers when implemented using a Virtual Private Network solution. It will be submitted VoIP traffic in two situations: without VPN and with VPN. The result will be analyzed based on ITU-T recommendation G.107 (E-Model), which describes an objective method to analyze transmission parameters that affect communication quality.

1

1. CAPÍTULO 1 – INTRODUÇÃO

A tecnologia de transmissão de pacotes de voz em redes de dados sobre o

protocolo Internet Protocol (IP), denominada Voz sobre IP (VoIP), evoluiu muito nos

últimos anos. Ela tem se tornado quase obrigatória nas grandes empresas além de

estar sendo objeto de desejo das demais. A razão principal é a redução de custos,

principalmente com ligações telefônicas externas (DELLOITTE, 2004).

Entre as grandes empresas que mais utilizam tecnologia no Brasil, 80%

adotam VoIP na integração de voz e dados (CARDOSO, 2005). Nas pequenas

empresas, 14% já usam ou adotarão VoIP até 2007. Entretanto, a expectativa é que

o percentual

de

(GREENE, 2006).

pequenas

empresas

usuárias

de

VoIP

triplique

até

2010

Mas, essa implementação de VoIP deve ser feita com cautela, principalmente

levando em consideração questões como a segurança e o desempenho. O tráfego

de voz pela rede assim como o de dados, também precisa atender requisitos de

segurança, dentre eles a confidencialidade. O desempenho da infra-estrutura de

rede influencia diretamente na qualidade da voz (WALLINGFORD, 2005).

Uma das formas de implementar confidencialidade em VoIP é o uso de VPN e

uma das formas de reduzir custos com aquisições para essa implementação é o uso

de software livre como o Linux (SANT’ANNA, 2003).

2

Wallingford (2005) sugere que seja evitado o uso de tráfego de VoIP através

de VPN, a não ser que seja absolutamente necessário. Ele afirma que “

é possível

usar VPN para tráfego de voz, mas a qualidade e a consistência desse tráfego de

voz serão imprevisíveis.” (WALLINGFORD, 2005, tradução nossa). E qual será o

impacto na qualidade da voz se ela trafegar por uma VPN? É com base nessa

questão que esse trabalho se desenvolve.

1.1

Objetivos

1.1.1

Geral

Este trabalho tem como objetivo geral, analisar o impacto que uma Rede

Privada Virtual provoca na qualidade do tráfego de Voz sobre IP.

1.1.2 Específicos

Para atender o objetivo geral deste trabalho, faz-se necessário:

Um estudo da tecnologia de Voz Sobre IP;

Um estudo de Rede Privada Virtual;

Implementar uma solução de VPN para Linux, dentre as citadas abaixo:

o

Poptop

(implementação

do

protocolo

Point-to-Point

Tunneling

Protocol – PPTP)

 

o

OpenSWAN (Implementação do Protocolo Internet Protocol Security

IPSec)

o

OpenVPN (Implementação de VPN que usa o protocolo Secure Socket

Layer/Transport Layer Security – SSL/TLS)

3

Submeter tráfego de VoIP em duas situações: sem passar pela VPN e

passando através da VPN.

Analisar o resultado com base na recomendação G.107 (E-Model) do

Telecommunication

Telecommunication

Standardization

Union

(ITU-T).

Essa

Sector

of

recomendação

International

descreve

um

método objetivo de análise de parâmetros em uma transmissão que

afetam a qualidade da comunicação.

1.2 Justificativas

Como as soluções de VPN são voltadas para tráfego de dados, o uso das

mesmas no tráfego de VoIP pode comprometer o desempenho e a qualidade da voz.

A análise a ser feita aqui visa identificar o quanto de impacto pode sofrer o

tráfego de VoIP em uma VPN.

A escolha da solução Linux é devido ao menor custo por ser software livre. A

escolha das soluções de VPN leva em consideração os padrões definidos pelo

Internet Engineering Task Force 1 (IETF) e as tecnologias suportadas pelo Virtual

Private Network Consortium 2 (VPNC).

1.3 Resultados Esperados

Com esse trabalho, espera-se obter subsídios que auxiliem na decisão de

adotar ou não uma solução de VPN em uma implementação de Voz sobre IP entre

pontos remotos de uma empresa, como no caso de filiais e matriz e vice-versa.

1 www.ietf.org - comunidade internacional aberta com a missão de criar soluções técnicas para a evolução da Internet

2

www.vpnc.org - associação internacional de fabricantes que atuam no mercado de VPN

4

1.4

Estrutura do Trabalho

Este trabalho é composto por seis capítulos e referências bibliográficas,

conforme descrito a seguir.

Capítulo

1

Introdução:

Apresenta

os

objetivos

geral

e

específicos,

justificativas, resultados esperados e a estrutura do trabalho.

Capítulo 2 – Voz sobre IP (VoIP): Descreve métodos de codificação de voz

para transporte em rede de dados, problemas que interferem na qualidade de voz e

métodos de teste do nível dessa qualidade.

Capitulo 3 – Rede Privada Virtual (VPN): Apresenta uma visão geral de VPN,

de Tunelamento e os protocolos utilizados.

Capítulo 4 – VPN em Linux: Apresenta as principais soluções de Rede

Privada Virtual implementadas sob o sistema operacional Linux, além de mostrar

fatores que afetam o desempenho de uma VPN sob o mesmo.

Capítulo 5 – Experimentos: Descreve o objetivo a ser alcançado, o ambiente

de testes, a metodologia e as ferramentas utilizadas na análise do comportamento

de Voz sobre IP em VPN sob Linux.

Capítulo 6 – Resultados: Apresenta os resultados obtidos na implementação

realizada no capítulo anterior, a conclusão do trabalho e sugestão para trabalhos

futuros.

5

2. CAPÍTULO 2 - VOZ SOBRE IP (VOIP)

A Rede Telefônica Pública Comutada (Public Switched Telephone Network -

PSTN) tem evoluído desde a primeira transmissão de voz realizada por Alexander

Graham Bell em 1876. Nas últimas décadas, o modo de transmissão do sinal de voz

mudou de analógico para digital permitindo que seu armazenamento e transmissão

sejam feitos de forma mais eficiente (DAVIDSON, 2000).

Isso também tornou possível mensurar e identificar um crescimento no

volume de dados transportados pela PSTN, que em 2002 chegou a ultrapassar o

volume do tráfego de voz. A queda nos custos das conexões de Internet e o

interesse das operadoras de redes de dados em transportar voz em sua infra-

estrutura, fizeram surgir a Telefonia pela Internet (TANEMBAUM, 2003). Também

denominada de Voz sobre IP (Voice over IP – VoIP), essa é a tecnologia usada para

transportar codificação de voz através de redes baseadas no protocolo IP, como a

Internet.

6

2.1

Codificação de voz

O método inicial usado na transmissão digital de voz foi a codificação PCM

(Pulse Code Modulation – Modulação por Codificação de Pulsos), padronizado pelo

ITU-T com a recomendação G.711. Ele é o tipo de codificação que procura

reproduzir o sinal amostra por amostra, possui baixo atraso para o processo e

pequena complexidade.

O PCM consiste em 8.000 amostragens do sinal de voz contínuo, por

segundo, representando o valor discreto amostrado em 8 bits. Isto implica na

necessidade de um canal digital de 64Kbps (8.000 amostragens x 8 bits = 64.000)

para transmissão de cada canal de voz. Existem duas variantes na recomendação

G.711, denominadas de a-law e µ-law. A-law é o padrão utilizado em circuitos

internacionais, sendo responsabilidade de quem usa µ-law fazer a conversão para a

outra variante ao efetuar uma chamada internacional (DAVIDSON, 2000).

Com o passar dos anos, foram desenvolvidas novas técnicas de codificação

que exploram os modelos de produção de voz e conseguem reduzir a largura de

banda necessária para transmissão de cada canal de voz. O ITU-T padronizou

essas codificações na sua série G de recomendações. As principais estão listadas

na Tabela 1, com outras informações relevantes como a codificação usada e a taxa

de transferência (em Kbps).

Recomendação

Codificação

Taxas (Kbps)

G.711

PCM

64

G.726

ADPCM

40, 32, 24 e 16

G.728

LD-CELP

16

G.729

CS-ACELP

8

G.723.1

MP-MLQ

6,3

G.723.1

ACELP

5,3

Tabela 1 – Principais recomendações ITU-T para codificação de voz (codec) Fonte: (DAVIDSON, 2000)

7

2.2

Problemas com qualidade da voz

De acordo

com Szigeti (2005), são três os fatores que mais afetam a

qualidade de voz em uma rede:

Atraso (ou Latência);

Variação do atraso (jitter);

Perda de pacotes;

Além disso, Szigeti (2005) também cita que uma largura de banda mínima

disponível para o tráfego da voz também deve ser levada em consideração. A seguir

descrevemos brevemente cada um desses fatores.

2.2.1 Atraso (ou Latência)

Em VoIP, atraso ou latência é caracterizado como o tempo que a voz leva

para sair da boca de quem fala e ser ouvida pelo interlocutor do outro lado de uma

comunicação telefônica (DAVIDSON, 2000). Esse tempo, chamado atraso fim-a-fim,

deve estar dentro de um patamar adequado de forma que não degrade a qualidade

da aplicação. Atrasos de até 150 ms são aceitáveis para a maioria das aplicações,

incluindo as de VoIP. Quando esse atraso está entre 150 e 400 ms deve ser

avaliado o impacto na qualidade da aplicação. Se ele for superior a 400 ms

geralmente é inaceitável pelas aplicações (ITU-T Recommendation G.114, 1996).

O atraso fim-a-fim é compreendido de dois componentes: o atraso fixo de

rede e o atraso variável de rede. Em redes de dados que transportam voz, o atraso

fixo de rede é dividido da seguinte forma (SZIGETI, 2005):

8

Atraso de empacotamento – É o tempo requerido para amostragem e

codificação do sinal de voz em pacotes.

Atraso de serialização – É o tempo requerido para transmitir os bits do

pacote no meio físico, baseado na velocidade do dispositivo de rede.

Atraso de propagação – É o tempo requerido para o pulso elétrico ou óptico

percorrer o meio físico da origem até o destino, baseado nas leis da física.

2.2.2

Variação do atraso (jitter)

A variação do atraso (jitter) é a diferença entre o tempo previsto de chegada

de um pacote e o tempo que ele realmente chega ao destino. Ele faz com que

pacotes cheguem fora de ordem, deixando áreas vazias na seqüência dos pacotes

de voz (DAVIDSON, 2000).

O jitter muda, em tempo real, em função do congestionamento do tráfego na

rede. Para minimizar essa variação de atraso, aplicações e equipamentos de VoIP

normalmente implementam um recurso chamado jitter buffer, que consiste em

armazenar os pacotes que chegam antecipadamente e esperar a chegada daquele

que está fora de ordem. Com isso, podem ocorrer duas situações denominadas

buffer underrun e buffer overrun (SZIGETI, 2005).

O buffer underrun ocorre quando o tempo de chegada dos pacotes aumenta

tanto que o jitter buffer fica sem pacotes para repassar ao processador de sinais

digitais. Isso resulta em cortes na voz. O buffer overrun ocorre quando os pacotes

chegam em uma velocidade maior do que a capacidade de armazenamento do jitter

buffer. Quando isso acontece, esses pacotes são descartados provocando uma

degradação na qualidade da voz (SZIGETI, 2005).

9

2.2.3 Perda de pacotes

A perda de pacotes ocorre quando a rede não consegue entregar um pacote

corretamente ao seu destino num período de tempo esperado. A Voz sobre IP é

projetada para suportar baixas taxas de perda de pacotes (próximo de 0%), contudo,

quando estas se tornam elevadas o serviço é degradado. Nas redes atuais, a perda

de pacotes ocorre basicamente devido a erro de bits na camada de enlace, por

falhas

na

rede

(SZIGETI, 2005).

A

maioria

e

dos

por

descarte

protocolos

de

devido

a

aplicação

congestionamento

de

de

dados,

tais

como

tráfego

o

TCP

(Transmission Control Protocol), automaticamente retransmite os pacotes perdidos.

Devido a sua característica de tempo real, as aplicações de VoIP utilizam os

protocolos UDP (User Datagram Protocol) e RTP (Real-Time Protocol) que não

efetua a retransmissão dos pacotes perdidos, visto que ela contribui para o aumento

do atraso (DAVIDSON, 2000).

2.2.4 Largura de Banda (Bandwidth)

Conforme foi visto na Tabela 1, cada codificação de voz tem necessidade de

uma determinada taxa de transferência por canal de voz. Porém, a largura de banda

que cada canal de VoIP consome é maior, como pode ser visto na Tabela 2. Isso

ocorre porque são acrescidos bytes adicionais aos pacotes de voz, chamados de

overhead. Esses bytes adicionais são os cabeçalhos dos protocolos (RTP, UDP e

IP) usados na transmissão, que equivalem a 40 bytes por pacote quando não se usa

compactação de cabeçalho (DAVIDSON, 2000).

10

Codificação

Intervalo de

Tamanho

Pacotes

Largura de banda por canal de voz

de voz

amostragem

do pacote

por

de voz

segundo

(em bytes)

 

G.711

20

ms

160

50

80

kbps

G.711

30

ms

240

33

74

kbps

G.729

20

ms

20

50

24

kbps

G.729

30

ms

30

33

19

kbps

Tabela 2 - Efeito de algumas codificações de voz na largura de banda Fonte: (SZIGETI, 2005)

Existe também um overhead adicional na camada de enlace, cujo tamanho

varia de acordo com a tecnologia usada na transmissão. A quantidade de bytes

adicionais de algumas dessas tecnologias está listada abaixo, conforme está em

Szigeti (2005).

Ethernet 802.1Q – adiciona até 32 bytes

Point-to-Point Protocol (PPP) – adiciona 12 bytes

Multilink PPP (MLP) – adiciona 13 bytes

Frame Relay – adiciona de 4 bytes; com FRF.12 1 adiciona 8 bytes.

A Tabela 3 mostra como fica a necessidade de largura de banda quando se

leva em consideração o overhead da camada de enlace.

Codificação de voz

Ethernet

PPP

MLP

 

Frame

802.1Q

Relay

com

FRF.121

G.711 com 50 pps

93

kbps

84

kbps

86

kbps

84

kbps

G.711 com 33 pps

83

kbps

77

kbps

78

kbps

77

kbps

G.729 com 50 pps

37

kbps

28

kbps

30

kbps

28

kbps

G.729 com 33 pps

27

kbps

21

kbps

22

kbps

21

kbps

Tabela 3 – Largura de banda incluindo o overhead da camada de enlace Fonte: (SZIGETI, 2005)

1 FRF-12 (Frame Relay Fragmentation 12) é um padrão que permite a fragmentação de quadros em redes Frame Relay

11

2.3

Métodos de Teste de Qualidade Voz

Cada tipo de codificação de voz é desenvolvido e ajustado com base em uma

medida subjetiva (percepção humana) de qualidade de voz.

Essa qualidade deve

ser classificada segundo algum critério. Um método de classificação muito usado é o

MOS

(Mean

Opinion

Score),

(DAVIDSON, 2000).

definido

na

recomendação

P.800

do

ITU-T

O método consiste em submeter a um grupo de pessoas, várias amostras de

voz decodificada, sendo o mais variado possível e envolvendo vozes masculinas e

femininas em igual quantidade. Cada ouvinte atribui uma pontuação numa escala de

1 a 5. Após isso, é feita então a média das pontuações para se obter o escore do

MOS (ITU-T Recommendation P.800, 1996.). A Tabela 4 apresenta a escala do

MOS para qualidade e esforço de entendimento (LE – Listening Effort).

Escore

Qualidade

Esforço para entendimento (LE)

5

Excelente

Um sinal de voz perfeito gravado em um local silencioso

4

Bom

Qualidade de uma chamada telefônica de longa distância (PSTN)

3

Razoável

Requer algum esforço na escuta

2

Pobre

Fala de baixa qualidade e difícil de entender

1

Ruim

Fala não clara, quebrada

Tabela 4 – Escala da qualidade e do esforço para entendimento (MOS e MOS-LE) Fonte: ITU-T Recommendation P.800 (1996)

Como

a

obtenção

de

escore

do

MOS

é

um

procedimento

de

difícil

reprodução, o desenvolvimento e implementação de métodos objetivos que possam

estimá-lo tem sido uma alternativa mais utilizada (CARVALHO, 2003). Entre esses

métodos objetivos, se destacam as recomendações G.107 (E-Model) e P.862

(PESQ) do ITU-T que são descritas a seguir.

12

2.3.1

E-Model

A recomendação G.107, denominada E-Model - a computacional model for

use in transmission plan, implementa um mecanismo baseado na soma de termos

que representam distorções na qualidade da voz, tais como atrasos de transmissão,

eco, distorções introduzidas pelos equipamentos utilizados, entre outros fatores. O

resultado do modelo é o fator escalar R que é gerado em uma escala de 0 a 100

mapeável para a escala de escore do MOS. O fator R igual a zero representa uma

qualidade extremamente ruim e o fator R igual a 100 representa uma qualidade

muito alta. A recomendação G.107 provê uma tabela que serve de orientação para

interpretar fatores R calculados com a finalidade de planejamento.

Ela também

apresenta a equivalência do fator R com o MOS. (ITU-T Recommendation G.107,

1998). A Tabela 5 é uma representação da existente na recomendação G.107.

Fator R

MOS

Satisfação dos usuários

(menor

(menor

limite)

limite)

90

4,34

Muito satisfeitos

80

4,03

Satisfeitos

70

3,60

Alguns usuários insatisfeitos

60

3,10

Muitos usuários insatisfeitos

50

2,58

Quase todos insatisfeitos

Tabela 5 - Relação entre o fator R e a satisfação do usuário Fonte: ITU-T Recommendation G.107 (1998)

13

2.3.2

PESQ

 

A

recomendação P.862, denominada Perceptual evaluation of speech quality

(PESQ):

An

objective

method

for

end-to-end

speech

quality

assesment

of

narrowband telephone networks and speech codecs, prediz automaticamente os

escores de qualidade de voz que seriam encontrados em um teste subjetivo típico.

Consiste em injetar um sinal de voz em um lado, capturar o sinal no outro lado e

fazer uma análise comparativa dos dois usando um modelo de percepção psico-

acústica que reflete com maior precisão a percepção humana do aparelho telefônico.

Possui uma escala de escore de -1 a 4,5 que também é mapeável para a escala do

MOS (ITU-T Recommendation P.862, 2001).

2.4

Conclusão

Apresentou-se uma visão geral de VoIP, descreveu-se os métodos de

codificação de voz para transporte em rede de dados, problemas que interferem na

qualidade de voz e métodos de teste do nível dessa qualidade. O conhecimento

dessas informações é de extrema importância para o objetivo que se deseja

alcançar com este trabalho.

O próximo capítulo apresentará uma visão geral de VPN, de Tunelamento e

os protocolos utilizados.

14

3. CAPÍTULO 3 – REDE VIRTUAL PRIVADA (VPN)

3.1

Visão Geral

Rede Privada Virtual (Virtual Private Network - VPN) é uma forma de simular

uma rede privada usando uma estrutura de rede pública, como a Internet. Uma VPN,

conforme

demonstrado

na

Figura

1,

permite

o

envio

de

dados

entre

dois

computadores através de uma rede pública de forma que emule propriedades de

uma ligação privada ponto a ponto (SCOTT 1999).

de uma ligação privada ponto a ponto (SCOTT 1999). Figura 1 – Lógica de VPN Fonte:

Figura 1 – Lógica de VPN Fonte: Adaptada de MICROSOFT CORPORATION, 2001

15

Todo tráfego de uma VPN Segura deve ser criptografado e autenticado. As

propriedades de segurança devem ser de comum acordo entre as partes envolvidas

na

VPN e

não deve permitir que ninguém de fora da VPN comprometa as

propriedades de segurança definidas (VPNC, 2006).

3.2

Tunelamento

Para

emular

uma

ligação

ponto

a

ponto,

os

dados

(payload)

são

encapsulados, ou envolvidos, com um cabeçalho (header) que provê as informações

de roteamento para permitir que eles cruzem a rede pública (transit internetwork) e

alcancem seu destino, como se houvesse um túnel (tunnel) entre as duas redes,

como pode ser visto na Figura 1. Para emular uma ligação privada, o dado enviado é

criptografado de forma a garantir a privacidade da informação, criando uma VPN

Segura (VPNC, 2006).

da informação, criando uma VPN Segura (VPNC, 2006). Figura 2 – Tunelamento Fonte: MICROSOFT CORPORATION, 2001

Figura 2 – Tunelamento Fonte: MICROSOFT CORPORATION, 2001

Conexões

virtuais

podem

ser

criadas

entre

dois

computadores,

um

computador e uma rede ou entre duas redes. A VPN entre duas redes, que é

transparente ao usuário, pode ser chamada de VPN de roteador para roteador. Nela,

o túnel VPN é iniciado e finalizado nos roteadores das empresas. Dessa forma, é

possível conectar matrizes, filiais e departamentos geograficamente dispersos, sem

a necessidade de gastos com linhas dedicadas (RESENDE, 2004).

16

3.3

Protocolos de Tunelamento

Para um túnel ser estabelecido entre dois pontos é necessário que ambos

estejam

usando

o

mesmo

protocolo

de

tunelamento.

Novas

tecnologias

de

tunelamento têm sido introduzidas nos últimos anos, com destaque para o Point-to-

Point Tunneling Protocol (PPTP), o Layer Two Tunneling Protocol (L2TP), o IPSec e

o

Secure

Socket

Layer/Transport

Layer

Security

(SSL/TLS)

(MICROSOFT

CORPORATION, 2001). Essas tecnologias serão abordadas mais adiante neste

capítulo. Todos esses protocolos são padronizados pelo Internet Engineering Task

Force (IETF) e suportados pelo Virtual Private Network Consortium (VPNC).

Alguns protocolos de tunelamento dependem de recursos originalmente

especificadas no protocolo PPP (MICROSOFT CORPORATION, 2001). É importante

conhecê-lo um pouco antes de detalhar os protocolos de tunelamento.

O Point-to-Point Protocol, especificado na RFC 1661, foi projetado para enviar

dados através de conexões discadas ou conexões ponto-a-ponto dedicadas. Ele

padroniza um método para transportar datagramas de múltiplos protocolos através

de ligações ponto a ponto e visa simplificar a interligação entre servidores, pontes e

roteadores. (SIMPSON, 1994).

A maioria das implementações do PPP já provê método de autenticação entre

os

pontos,

tais

como

Authentication

Protocol

(PAP),

Challenge

Handshake

Authentication Protocol (CHAP), e Microsoft Challenge Handshake Authentication

Protocol

(MS-CHAP).

A

carga

do

quadro

PPP

pode

ser

criptografado

e/ou

comprimido. No caso da implementação da Microsoft, é usado o Microsoft Point-to-

Point Compression Protocol (MPPC) para compressão e o Microsoft Point-to-point

Encryption (MPPE) para criptografia (MICROSOFT CORPORATION, 2001).

17

3.3.1 PPTP (Point-to-Point Tunneling Protocol)

O protocolo PPTP, uma extensão do PPP, usa um modelo cliente-servidor

para estabelecer conexão de VPN. Ele encapsula pacotes PPP em datagramas IP.

O túnel do PPTP é feito usando uma versão modificada do protocolo Generic

Routing Encapsulation (GRE), criado para permitir múltiplos protocolos trafegarem

através de túneis IP. Com isso, o PPTP suporta o tráfego de outros protocolos tais

como IPX e NetBEUI, além do próprio IP (HAMZEH, 1999).

A

Figura

3

mostra

a

estrutura

de

criptografados do usuário.

um

pacote

PPTP

Criptografado

contendo

dados

do usuário. um pacote PPTP Criptografado contendo dados Cabeçalho Cabeçalho Cabeçalho Carga do PPP
do usuário. um pacote PPTP Criptografado contendo dados Cabeçalho Cabeçalho Cabeçalho Carga do PPP
do usuário. um pacote PPTP Criptografado contendo dados Cabeçalho Cabeçalho Cabeçalho Carga do PPP
do usuário. um pacote PPTP Criptografado contendo dados Cabeçalho Cabeçalho Cabeçalho Carga do PPP

Cabeçalho

Cabeçalho

Cabeçalho

Carga do PPP (datagrama IP ou IPX, quadro NetBEUI)

IP

GRE

PPP

(datagrama IP ou IPX, quadro NetBEUI) IP GRE PPP Quadro PPP Figura 3 – Estrutura de

Quadro PPP

IP ou IPX, quadro NetBEUI) IP GRE PPP Quadro PPP Figura 3 – Estrutura de um

Figura 3 – Estrutura de um pacote PPTP Fonte: Adaptado de MICROSOFT CORPORATION, 2001

18

3.3.2 L2TP (Layer 2 Tunneling Protocol)

L2TP é uma combinação do PPTP e do Layer 2 Forwarding (L2F), uma

tecnologia proposta pela Cisco. Aproveitando o melhor das duas tecnologias, o L2TP

encapsula quadros PPP para enviar através de redes IP, X.25, Frame Relay ou

Asynchronous Transfer Mode (ATM). Quando transporta seus datagramas através

de rede IP, ele pode ser usado como protocolo de tunelamento na Internet. O L2TP

sobre rede IP usa o protocolo UDP e uma série de mensagens L2TP para a

manutenção do túnel. Ele também usa UDP para enviar quadros PPP encapsulados

em L2TP (MICROSOFT CORPORATION, 2001; TOWNSLEY, 1999), como pode ser

visto na Figura 4.

Cabeçalho

Cabeçalho

Cabeçalho

Cabeçalho

PPP Payload (datagram IP ou IPX, quadro NetBEUI)

IP

UDP

L2TP

PPP

 
Quadro PPP Quadro L2TP Mensagem UDP

Quadro PPP

Quadro PPP Quadro L2TP Mensagem UDP

Quadro L2TP

Quadro PPP Quadro L2TP Mensagem UDP

Mensagem UDP

Quadro PPP Quadro L2TP Mensagem UDP

Figura 4 – Estrutura de um pacote L2TP Fonte: Adaptado de MICROSOFT CORPORATION, 2001

De acordo com SCOTT (1999), o IPSec é o mecanismo de criptografia

recomendado para o L2TP. A Figura 5 mostra o resultado de um pacote L2TP

criptografado com IPSec. No próximo tópico será abordado com mais detalhes o

funcionamento do IPSec

19

19 Figura 5 – Estrutura de um pacote L2TP criptografado com IPSec Fonte: MICROSOFT CORPORATION, 2001

Figura 5 – Estrutura de um pacote L2TP criptografado com IPSec Fonte: MICROSOFT CORPORATION, 2001

3.3.3 IPSec (Internet Protocol Security)

O protocolo IPSec foi desenvolvido pelo IETF como um mecanismo fim-a-fim

para garantir segurança de dados em comunicações baseadas no protocolo IP tanto

na versão 4 (IPv4) como na versão 6 (IPv6). O conjunto de serviços oferecido pelo

IPSec inclui o controle de acesso, integridade da informação, autenticação na origem

dos dados, rejeição a ataques do tipo replay (onde parte de uma transmissão da

rede é copiada e reproduzida posteriormente) e confidencialidade (criptografia).

Esses serviços são oferecidos na camada do IP, podendo ser usados por qualquer

protocolo de camada superior, como por exemplo, UDP, TCP, etc (KENT, 1998c).

Para prover a segurança no tráfego o IPSec usa dois protocolos que podem

ser aplicados em conjunto ou separadamente (KENT, 1998c):

Authentication Header (AH) que provê integridade da informação e autenticação

na origem e;

Encapsulating Security Payload (ESP) que trata da criptografia e autenticação;

20

Cada protocolo suporta dois modos de uso: modo de transporte e modo túnel.

Eles são estabelecidos através de Security Association (SA), que é uma relação

entre duas ou mais entidades que descreve como elas usarão os serviços de

segurança para uma comunicação segura (MASON, 2001).

No modo túnel, todo o pacote IP original é encapsulado em um novo pacote

IP, conforme demonstra a Figura 6. O modo túnel é comumente utilizado na

comunicação entre roteadores para interligar redes. (KENT, 1998c; MASON, 2001).

para interligar redes. (KENT, 1998c; MASON, 2001). Figura 6 – Estrutura do pacote IPSec em modo

Figura 6 – Estrutura do pacote IPSec em modo túnel Fonte: Adaptado de KOLESNIKOV, 2002

No modo de transporte, o cabeçalho IPSec é adicionado entre o cabeçalho IP

original e os dados, como pode ser visto na Figura 7. Este modo é utilizado entre

computadores comunicando-se diretamente entre si e que desejam proteger o seu

tráfego IP (KENT, 1998c; MASON, 2001).

proteger o seu tráfego IP (KENT, 1998c; MASON, 2001). Figura 7 – Estrutura do pacote IPSec

Figura 7 – Estrutura do pacote IPSec em modo transporte Fonte: Adaptado de KOLESNIKOV, 2002

21

O modo túnel acrescenta 20 bytes a mais por pacote comparado com o modo

transporte. No caso de uma codificação de voz G.711, isso aumenta a taxa de 80

kbps para 112 kbps (SZIGETI, 2005).

3.3.4 SSL/TLS (Secure Socket Layer/ Transport Layer Security)

O SSL é um protocolo criado pela Netscape 1 para prover privacidade na

comunicação entre aplicações cliente/servidor.

Ele foi projetado para fazer uso do

TCP como uma camada de comunicação que provê uma conexão fim-a-fim segura e

autenticada entre dois pontos da rede (ONYSZKO 2004). De fato, o SSL é um

composto por um conjunto de protocolos que adicionalmente podem ser divididos

em duas camadas:

1. O protocolo que garante a segurança e a integridade da informação: SSL

Record.

2. Os protocolos projetados para estabelecer uma conexão SSL, que são: SSL

Handshake, SSL ChangeCipher SpecProtocol e o SSL Alert Protocol.

A Figura 8 ilustra a pilha do protocolo SSL com as camadas citadas.

8 ilustra a pilha do protocolo SSL com as camadas citadas. Figura 8 - Pilha do

Figura 8 - Pilha do protocolo SSL Fonte: ONYSZKO, 2004

1 www.netscape.com

22

Adotando o SSL 3.0 como ponto de partida, o IETF publicou em 1999 a RFC

2246 que define o protocolo Transport Layer Security (TLS) em sua versão 1.0. O

principal objetivo do TLS é tornar a comunicação mais segura do que no SSL e fazer

a especificação

do

ONYSZKO, 2004).

3.4

Conclusão

protocolo

mais

precisa

e

completa

(DIERKS,

1999;

Apresentou-se uma visão geral de Rede Privada Virtual, de Tunelamento e

descreveu-se os protocolos de tunelamento utilizados. Com essas informações já se

tem uma noção do impacto que uma VPN pode ocasionar no tráfego de Voz sobre

IP, pois já é sabido que adicionará um overhead.

No próximo capítulo serão apresentadas as principais soluções de VPN

implementadas sob o sistema operacional Linux, além de mostrar fatores que afetam

o desempenho de uma VPN em Linux.

23

4. CAPÍTULO 4 – VPN EM LINUX

4.1

Visão Geral

O Linux surgiu como uma variante do sistema operacional UNIX 1 para a

arquitetura de computadores padrão IBM PC. A versão inicial foi escrita por Linus

Torvalds, um estudante Finlandês de ciência da computação. Em 1991 ele postou na

Internet uma primeira versão do Linux. Desde então, pessoas através da Internet

têm contribuído para o desenvolvimento do mesmo. A chave do sucesso do Linux

tem sido o fato dele ser um sistema operacional gratuito, disponibilizado inclusive

com o código fonte, e pela qualidade do seu kernel, o núcleo do sistema operacional

(STALLINGS, 2005).

O fator custo é bem relevante na implementação de uma VPN (GLEESON,

2000). O sistema operacional Linux, como solução aberta e gratuita, é uma

alternativa a ser considerada neste caso. Apesar de existirem soluções comerciais

para Linux que têm um custo, é possível e viável interligar redes através de VPN

com Linux usando somente soluções abertas (SANT’ANNA, 2003).

1 UNIX é um sistema operacional criado nos anos 70 pela Bell Labs

24

O uso de servidores Linux para soluções VPN atende diversos cenários,

desde usuários em diferentes pontos que precisam acessar remotamente a rede

local até a interligação de redes. Aqui serão analisadas as soluções com base no

cenário de interligação de duas redes através de uma VPN, conforme ilustrado na

Figura 9.

redes através de uma VPN, conforme ilustrado na Figura 9. Figura 9 – Exemplo de VPN

Figura 9 – Exemplo de VPN com Linux Fonte: Adaptada de KOLESNIKOV, 2002

Em cada rede é necessário instalar um servidor Linux com o software de VPN

devidamente configurado. Cada servidor Linux atuará como roteador para alcançar a

outra rede. A VPN é estabelecida entre ambos (KOLESNIKOV, 2002).

4.2

Soluções

Dentre as várias alternativas de VPN implementadas para Linux e com código

aberto, este trabalho destaca aquelas que implementam padrões definidos pelo IETF

e tecnologias suportadas pelo VPNC, como é o caso do Poptop, projeto S/WAN e o

OpenVPN, explanadas a seguir.

25

4.2.1 Poptop

O Poptop é a solução de Servidor PPTP (Point-to-Point Tunneling Protocol)

para Linux e plataformas similares como OpenBSD e FreeBSD. De acordo com

WALDIE (2006), os recursos que o Poptop oferece incluem:

Compatibilidade com autenticação e criptografia da Microsoft (MS-CHAP v2 e

MPPE);

Suporta múltiplas conexões de clientes;

Integração com ambiente de rede Microsoft usando um plugin (Um aplicativo

auxiliar que adiciona novas capacidades ao aplicativo original);

Funciona com diversos clientes PPTP, tanto na plataforma Windows como Linux.

4.2.2 S/WAN

S/WAN é o nome de um projeto criado com o propósito de implementar Rede

de Longa Distância Segura (Secure Wide Area Network). Como o programa

desenvolvido

pelo

projeto

era

software

livre

(Free),

o

nome

do

produto

foi

denominado de FreeS/WAN, que nada mais é do que uma implementação de IPSec

(Internet Protocol Security) para Linux. Por usar recursos de criptografia que

conflitavam com as leis de exportação americana, este projeto foi descontinuado,

ficando seu código fonte disponível (GILMORE, 2003).

26

A partir do código fonte do FreeS/WAN descontinuado, surgiram dois outros

projetos: o OpenSwan e o strongSwan. Ambos mantêm a implementação do IPSec

para o Linux, lançando diferentes versões, sendo que o foco do strongSwan está em

melhorar os métodos de criptografia e autenticação fazendo uso de certificados e

smartcards 1 (XELERANCE CORPORATION, 2006).

A implementação do IPSec no Linux consiste de uma porção do kernel e um

conjunto de utilitários. A porção do kernel implementada pelo SWAN é denominada

KLIPS (Kernel IP Security). Dependendo da distribuição Linux, faz-se necessário

recompilar o kernel para usar o Openswan/strongSwan. A partir da versão 2.6 do

kernel, essa porção que implementa o IPSec já está inclusa (LEEUW, 2006).

4.2.3

OpenVPN

OpenVPN é uma solução baseada no protocolo SSL/TLS que suporta vários

tipos de configurações, dentre elas VPN ponto-a-ponto com balanceamento de

carga, tolerância a falhas e controle de acesso refinado. O modelo de segurança do

OpenVPN tem por base o uso do protocolo SSL/TLS para autenticar uma sessão e o

protocolo ESP do IPSec para criar um túnel seguro de transporte sobre o protocolo

UDP. Como o SSL/TLS é projetado para operar sobre uma camada confiável, o que

não é o caso do protocolo UDP, o OpenVPN provê uma camada confiável própria

acima do UDP como pode ser visto na Figura 10 (OPENVPN SOLUTIONS LLC,

2006).

1 Cartão de circuito integrado por microprocessador, capaz de fazer cálculos e produzir uma assinatura digital (fonte: www.google.com)

27

SSL/TLS

Túnel IP

Camada Confiável

Criptografia

Multiplexador

UDP

Figura 10 – Camadas do OpenVPN Fonte: Adaptado de OPENVPN SOLUTIONS LLC, 2006

 

O

OpenVPN usa interfaces TUN/TAP. A interface TUN é um adaptador virtual

de

rede

que

atua

como

dispositivo

de

rede

ponto-a-ponto

para

o

sistema

operacional. Só que, ao invés de lidar com os bits em um fio ele os trata no nível do

usuário. Uma interface TAP é similar ao TUN, só que emulando um adaptador

Ethernet ao invés de um ponto-a-ponto (KRANYANSKY, 2001 ).

4.3

Desempenho

O desempenho de uma VPN em Linux depende de alguns fatores, incluindo o

tipo de solução adotada e o equipamento onde o sistema operacional está sendo

executado. Operações necessárias para o funcionamento da VPN, como criptografia

e seu processo inverso, compressão e descompressão dos dados, terão impacto no

desempenho

da

rede

(KOLESNIKOV, 2002).

quando

comparado

com

um

tráfego

sem

VPN

Para acompanhar esse desempenho, Kolesnikov (2002) recomenda fazer

medições do servidor e da rede usando ferramentas como o Multi Router Traffic

Grapher (MRTG).

28

O MRTG é uma ferramenta gratuita desenvolvida para monitorar a carga de

tráfego em links de rede gerando gráficos diário, semanal e mensal. Para obter as

estatísticas de rede, o MRTG coleta as informações através do Simple Network

Management Protocol (SNMP), um protocolo de gerenciamento de rede. O MRTG

também pode ser usado para monitorar outros objetos, como o uso do processador

de um computador, sendo necessário um módulo externo que colete as informações

e repasse para o MRTG (OETIKER, 2006).

Kolesnikov (2002) sugere também o uso da ferramenta Test TCP (ttcp), um

utilitário que mede o desempenho de tráfego TCP e/ou UDP entre dois pontos e já

faz parte de algumas distribuições Linux. Com ele é possível ter uma idéia do

overhead que a VPN provoca na rede.

4.4

Conclusão

Foram apresentadas as principais soluções de VPN implementadas sob o

sistema operacional Linux, além de ter sido mostrado fatores que afetam o

desempenho de uma VPN em Linux.

O próximo capítulo trata dos experimentos desse trabalho. Será descrito o

objetivo a ser alcançado, o ambiente de testes, a metodologia e as ferramentas

utilizadas na análise do comportamento de Voz sobre IP em VPN sob Linux.

29

5. CAPÍTULO 5 – EXPERIMENTOS

5.1 Objetivo

Com os experimentos realizados neste trabalho, é esperado verificar qual o

impacto que uma solução de VPN em Linux pode gerar qualidade da voz sobre IP e

obter subsídios que auxiliem na decisão de adotar ou não uma solução de VPN em

uma implementação de Voz sobre IP entre pontos remotos de uma empresa, como

no caso de filiais e matriz e vice-versa.

5.2 Ambiente de Testes

O ambiente de testes consistiu basicamente de três computadores em uma

estrutura de rede já existente, conforme pode ser observado na Figura 11.

em uma estrutura de rede já existente, conforme pode ser observado na Figura 11. Figura 11

Figura 11 – Ambiente de Testes

30

Dois computadores foram configurados com o sistema operacional Linux e um

terceiro com o sistema operacional Microsoft Windows XP Professional, pelo fato de

que um dos programas utilizados nos testes só funciona em ambiente Windows. A

Tabela 6 apresenta as configurações mais relevantes dos três computadores.

Computador

Processador

 

Memória

Windows XP

AMD Sempron 1580 Mhz

512

Mb

Linux 1

Intel Celeron 1000 Mhz

256

Mb

Linux 2

AMD Sempron 1600 Mhz

512

Mb

Tabela 6 - Configuração dos computadores

O computador com Windows XP estava conectado em rede com o Linux 1

através de placas de rede de 100 Mbits. O computador Linux 1 estava conectado à

Internet através de uma conexão de 256 kbps. O computador Linux 2, em uma

localidade diferente dos outros dois, também estava conectado à Internet através de

uma conexão Frame Relay de 256 kbps com CIR (Commited Information Rate) 1 de

60 kbps. Ambas as conexões de Internet estavam configuradas com endereço IP

público e estático.

Por uma questão de privacidade, os endereços IP apresentados neste

trabalho não correspondem aos endereços do ambiente de testes. A alteração

desses endereços IP não interfere no resultado esperado deste trabalho.

O uso da estrutura de rede para testes foi realizado em horário onde as duas

redes não tinham tráfego relevante nos links de Internet, com o objetivo de evitar que

algum tráfego adicional interferisse nos resultados dos testes. Isso pode ser

constatado nas Figuras 12 e 13, que apresentam os gráficos gerados antes dos

testes em cada um dos servidores Linux.

1 CIR é a largura de banda mínima garantida em uma conexão de Frame Relay

31

31 Figura 12 - Tráfego do Linux 1 antes dos testes Figura 13 - Tráfego do

Figura 12 - Tráfego do Linux 1 antes dos testes

31 Figura 12 - Tráfego do Linux 1 antes dos testes Figura 13 - Tráfego do

Figura 13 - Tráfego do Linux 2 antes dos testes

A legenda inferior de cada gráfico representa a hora. Observando a partir da

linha vertical correspondente às 20 horas, percebe-se que há uma redução do

tráfego a poucos bytes por segundo. Os testes foram realizados sempre a partir

desse horário e se estenderam até às 22 horas no máximo.

Esses

gráficos

foram

gerados

pelo

MRTG

com

base

em

informações

coletadas, via SNMP, da interface de rede conectada ao link de Internet. Antes dos

testes, eles sempre foram consultados para se ter certeza que não havia tráfego

relevante.

32

5.3

Softwares utilizados

Para medir o comportamento do tráfego de VoIP sobre VPN em Linux foi

usado o software IxChariot da

Ixia 1 .

Ele

é

um

programa que testa e mede o

desempenho entre um par de equipamentos em rede, gerando fluxo de dados que

emula o funcionamento de diferentes tipos de aplicações. O IxChariot é composto

basicamente de dois módulos: Os Performance Endpoints e o IxChariot Console.

Performance Endpoints são pequenos programas, também denominados

agentes, que são instalados em computadores da rede. Eles são responsáveis por

simular tráfego na rede (test data) de acordo com o tipo de aplicação que se deseja

testar. O IxChariot Console, uma interface gráfica para Windows, é responsável por

controlar os testes (test setup), coletar os resultados (test results) e gerar os

relatórios

(IXIA,

2004).

A

Figura

funcionamento do IxChariot.

12

apresenta

os

componentes

e

esse

No ambiente de testes deste trabalho, o Console do IxChariot versão 5.40 foi

instalado no computador com Windows XP e os agentes, versão 6.10, foram

instalados nos computadores Linux 1 e Linux 2.

1 www.ixiacom.com

33

33 Figura 14 – Ambiente do IxChariot Fonte: Adaptado de www.ixiacom.com A decisão em usar o

Figura 14 – Ambiente do IxChariot Fonte: Adaptado de www.ixiacom.com

A decisão em usar o IxChariot foi devido aos recursos oferecidos por ele que

condizem com as necessidades deste trabalho, os quais estão listados a seguir:

Licença de avaliação que permite o uso do produto com todas as funcionalidades

por três dias. Após esse período é necessário adquirir licença de uso.

Agentes que rodam no sistema operacional Linux.

Cinco tipos de codificadores de voz com diferentes algorítimos de compressão;

Métricas de desempenho e qualidade de voz que incluem jitter, perda de pacotes,

atraso e geração do MOS (Mean Opinion Score).

O IxChariot usa uma versão modificada do método E-Model para calcular o

fator R e o MOS estimado para cada ponto de teste. Ele usa os seguintes itens no

cálculo (IXIA, 2004):

Atraso fixo de rede (One-Way (Network) Delay) – Equivalente ao atraso de

propagação, sendo que o IxChariot determina esse atraso em uma só direção (de

um agente ao outro).

34

Atraso fim-a-fim (End-to-End Delay) – Calculado com base em um conjunto de

atrasos, que são: o fixo de rede, o de empacotamento, o de jitter buffer e o fixo

adicional.

Atraso de empacotamento (Packetization Delay) – Conversão do sinal de voz

analógico para digital e varia de acordo com o codec utilizado.

Atraso do Jitter Buffer (Jitter Buffer Delay) – Todo atraso relacionado ao jitter

buffer.

Atraso fixo adicional (Additional Fixed Delay) – Informado pelo usuário, quando o

equipamento de VoIP que será simulado possui um atraso fixo. Nos testes

realizados neste trabalho o valor será zero em razão de não haver nenhuma

relação direta com qualquer equipamento.

Perda de pacotes/dados (Data Loss) – Número total de pacotes perdidos.

Perda de Datagramas do Jitter Buffer (Jitter Buffer Lost Datagrams) – Número de

pacotes perdidos quando ocorrem buffer underrun e overrun.

Para realizar os experimentos deste trabalho foi escolhida a distribuição

brasileira Conectiva Linux versão 10, principalmente pelo fato do autor desse

trabalho ter maior familiaridade com as ferramentas que acompanham a mesma. O

kernel usado foi o 2.6.11 no padrão que veio na referida distribuição.

A solução de VPN escolhida foi o OpenVPN versão 2.0.7, a mais atual na

data em que se realizaram os experimentos deste trabalho. Os fatores que

influenciaram na decisão para a escolha desta solução foram:

Facilidade de implantação: seguindo as orientações da documentação existente

no site do produto, conseguiu-se colocar em funcionamento na primeira tentativa.

35

Compatibilidade do produto com o Conectiva Linux: não é necessária nenhuma

alteração no kernel e os pacotes necessários ao funcionamento já estão

disponíveis na respectiva distribuição do Linux. A única dificuldade foi identificar o

nome desses pacotes.

Uso do protocolo UDP como transporte, que é o mesmo utilizado pelos sistemas

VoIP para transporte dos pacotes de voz.

5.4

Preparação da VPN

Como o OpenVPN trabalha com o conceito de Cliente e Servidor para

identificar os pontos que formarão a VPN, é necessário definir que computador

representará cada função. Foi adotado que o Linux 1 será o Servidor e o Linux 2

será o Cliente. A instalação deve ser feita nos computadores que formarão a VPN.

Algumas configurações são necessárias somente no Servidor, como é detalhado em

seguida.

5.4.1 Instalação do OpenVPN

Para instalar o OpenVPN foi necessário executar os seguintes passos:

1. Efetuar o download do código fonte compactado:

wget http://openvpn.net/release/openvpn-2.0.7.tar.gz

2. Descompactar o código fonte:

tar xfzv openvpn-2.0.7.tar.gz

3. Configurar de acordo com o ambiente:

cd openvpn-2.0.7

./configure --disable-lzo --prefix=/usr

36

Para compilar o OpenVPN a partir do código fonte, faz-se necessário ter

algumas bibliotecas previamente instaladas no Linux. Em uma instalação mínima do

Conectiva Linux 10 foi necessário instalar o pacote openssl-devel, usando o

comando apt-get install openssl-devel. Caso isso não seja feito, não será

possível seguir adiante no processo. Diante disso, foi optado por usar a opção

--disable-lzo, que indica para compilar o programa sem uso da biblioteca de

compressão LZO (Lempel-Ziv-Oberhumer), devido a uma dificuldade em identificar a

referida biblioteca. Já a opção --prefix=/usr foi usada para seguir o padrão de

local onde o Conectiva Linux armazena os programas.

4. Compilar e instalar o programa:

make

make install

O OpenVPN já traz alguns scripts prontos. Um deles é para a inicialização do

programa em distribuições que seguem o padrão da Red Hat, como é o caso do

Conectiva Linux 10. O referido script foi copiado para o local devido com comando:

cp sample-scripts/openvpn.init /etc/init.d/openvpn

Por padrão, este script busca os arquivos de configuração do OpenVPN no

diretório /etc/openvpn, que foi necessário criar.

5.4.2 Preparação da infra-estrutura de chave pública

Feita a instalação, inicia-se o processo de configuração. O OpenVPN suporta

autenticação bidirecional baseada em certificados. Para isso, é necessário executar

alguns passos para preparar a infra-estrutura de certificados usando chave pública.

cp

easy-rsa/* /etc/openvpn

cd

/etc/openvpn

37

./clean-all

O comando ./clean-all apaga todas as chaves que porventura já tenham

sido criadas

./build-ca

É feita solicitação de preenchimento de opções na execução desta etapa. Foi

teclado <enter> em todas as opções, exceto em Common Name que foi digitado

OpenVPN-CA.

./build-key-server server

Aqui também é solicitado o preenchimento de opções na execução desta

etapa. Foi teclado <enter> em todas as opções, exceto em Common Name que foi

digitado Server e respondido y nas duas únicas perguntas de y/n.

./build-key vpn-client

O vpn-client é um nome para cada cliente de VPN que irá se conectar, pois

um servidor de OpenVPN aceita conexões de diversos clientes. Nos itens solicitados

a preencher, no Common Name foi digitado um nome para cada cliente (Cliente 1) e

respondido y nas duas únicas perguntas de y/n.

./build-dh

chmod 600 keys/*.key

Essa é uma medida de segurança para proteger os arquivos de chaves

privadas que foram gerados. Com isso, somente o superusuário do Linux, o root,

terá acesso a esses arquivos. Em seguida, os arquivos abaixo são copiados para o

diretório de configuração do OpenVPN.

cp keys/dh1024.pem /etc/openvpn

cp keys/server.crt /etc/openvpn

cp keys/server.key /etc/openvpn

cp keys/ca.* /etc/openvpn

38

Para o computador Cliente (Linux 2), são copiados os arquivos ca.crt,

vpn-client.crt e vpn-client.key e colocados no diretório de configuração do OpenVPN.

5.4.3 Arquivos de configuração do Servidor e do Cliente

Nos arquivos de configuração ficam os parâmetros para a formação da VPN.

Os arquivos de configuração do Servidor e do Cliente usados neste trabalho, são os

exemplos

que

acompanham

o

OpenVPN

com

pequenas

adaptações

para

o

ambiente de testes. Cada arquivo de configuração fica armazenado no diretório

/etc/openvpn do respectivo computador.

Conteúdo do arquivo de configuração do Servidor, denominado server.conf:

port 1194

proto udp

dev tun

ca ca.crt

cert server.crt

key server.key

dh dh1024.pem

server 192.168.200.0 255.255.255.0

ifconfig-pool-persist ipp.txt

keepalive 10 120

persist-key

persist-tun

status openvpn-status.log

verb 3

39

Conteúdo do arquivo de configuração do Cliente, denominado vpn-client.conf:

client

dev tun

proto udp

remote 200.200.200.200 1194

resolv-retry infinite

nobind

user nobody

group nobody

persist-key

persist-tun

ca ca.crt

cert vpn-client.crt

key vpn-client.key

ns-cert-type server

verb 3

mute 20

Ao término de todas as configurações foi inicializado o serviço do OpenVPN

nos dois computadores com Linux através do comando:

service openvpn start

Após isso, ficou ativa a VPN entre os dois computadores com Linux, cujas

configurações de endereçamento IP são apresentadas na Tabela 7 e na Figura 15.

40

 

Linux 1

Linux 2

Rede Local (eth0)

10.10.10.10/24

10.85.2.1/24

Internet (eth1)

200.100.100.100/24

200.200.200.200/24

OpenVPN (tun0)

192.168.200.1/24

192.168.200.10/24

Tabela 7 - Endereçamento IP do ambiente de testes

Tabela 7 - Endereçamento IP do ambiente de testes Figura 15 – Ambiente de Testes após

Figura 15 – Ambiente de Testes após configurada a VPN

5.5

Configuração do IxChariot

 

Para iniciar um teste de VoIP com o IxChariot, é necessário adicionar um par

de

pontos

que

tenham

os

agentes

instalados

e

informar

alguns

parâmetros

necessários para a realização deste teste. Dentre os diversos parâmetros possíveis

de configurar, somente os endereços IP dos dois pontos e o codificador de voz

(codec) utilizado foram informados. O codec utilizado foi o G.711a pelo fato do

mesmo

ser

o

padrão

utilizado

em

circuitos

internacionais.

Para

os

demais

parâmetros foram aceitas as configurações pré-definidas, como pode ser visto na

Figura 16.

41

41 Figura 16 - Tela de configuração de um par de teste para VoIP Para realizar

Figura 16 - Tela de configuração de um par de teste para VoIP

Para realizar os experimentos, foram configurados dois pares de testes: Um

denominado “Com VPN” e outro denominado “Sem VPN”. O que difere de um para

outro é somente o endereço IP dos pontos, onde o “Com VPN” usará o endereço

das interfaces usadas pelo OpenVPN e o “Sem VPN” usará o endereço IP das

interfaces das conexos de Internet de cada Linux, como pode ser observado na

Figura 17.

42

42 Figura 17 – Par de teste VoIP no IxChariot Console Antes de iniciar os testes,

Figura 17 – Par de teste VoIP no IxChariot Console

Antes de iniciar os testes, foi seguida a recomendação de Koleniskov (2002) e

executado o ttcp. Para instalar o ttcp no Conectiva 10, foi necessário fazer o

download do pacote RPM a partir do endereço

ftp://ftp.conectiva.com.br/pub/conectiva/10/i386/RPMS.extras/ttcp-1.4-

6644cl.i386.rpm e executar a instalação com o comando abaixo:

rpm –ivh ttcp-1.4-6644cl.i386.rpm

No computador Linux 2 foi executado o ttcp no modo receptor (ttcp –r). A

partir do computador Linux 1, foi executado um teste durante dois minutos que

consistiu em uma comunicação com o Linux 2 através do endereço IP público, cujo

resultado pode ser visto a seguir:

root@linux1 openvpn# ttcp -t 200.200.200.200 < openvpn-

2.0.7.tar.gz

ttcp-t: buflen=8192, nbuf=2048, align=16384/+0, port=5001 tcp -> 200.200.200.200 ttcp-t: socket ttcp-t: connect ttcp-t: 3596288 bytes in 117.46 real seconds = 29.90 KB/sec +++

A última

linha nos

mostra um taxa de

29,90 KB/sec. Em seguida, foi

executado outro teste que consistiu em uma comunicação com o Linux 2 através do

endereço IP privado usado pela VPN, cujo resultado pode ser visto abaixo.

root@linux1 openvpn# ttcp -t -p22 192.168.200.10 < openvpn-

2.0.7.tar.gz

ttcp-t: buflen=8192, nbuf=2048, align=16384/+0, port=5001 tcp -> 192.168.200.10 ttcp-t: socket ttcp-t: connect ttcp-t: 3481600 bytes in 120.09 real seconds = 28.31 KB/sec +++

43

Como se pode observar, a taxa deste segundo foi de 28,31 KB/sec, uma

diferença

de

aproximadamente

6%.

Isso

é

devido

ao

overhead

da

VPN

(KOLESNIKOV, 2002). Para evitar dúvidas relacionadas a tráfego no momento de

cada teste, eles foram repetidos por mais três vezes, obtendo resultados similares.

Após isso, foi disparado inicialmente o teste sem uso da VPN para depois ser

disparado o teste com o tráfego passando pela VPN. Cada teste, com uma duração

aproximada de 2 minutos e meio, foi repetido em três momentos diferentes. Os

resultados foram gravados em arquivos para serem analisados, o que ocorrerá no

próximo capítulo.

44

6. CAPÍTULO 6 – RESULTADOS

6.1

Resultados

O IxChariot produz uma série de resultados numéricos dos testes além de

alguns gráficos para análise. A Tabela 8 apresenta os resultados da primeira

execução dos dois testes de VoIP.

 

MOS

MOS

MOS

Fator-R

Atraso

Atraso

%

de

Perdas

Médio

Mínimo

Máximo

Médio

fixo

fim-a-fim

perda

do

de

jitter

rede

buffer

Sem

4,34

3,80

4,37

90,46

20

61

 

0

3

VPN

 

Com

4,25

2,45

4,37

88,26

25

66

0,013

10

VPN

Tabela 8 - Resultados do teste de VoIP

O resultado mais relevante na análise deste trabalho é o MOS (Mean Opinion

Score) que no E-model é gerado a partir do fator R. Porém, os outros fatores não

deixarão de ser analisados. Nas demais execuções dos testes, os valores obtidos

ficaram bem próximos dos apresentados na Tabela 8. Por isso, toda a análise dos

resultados foi feita com base na primeira execução dos testes.

45

No teste sem uso da VPN, o MOS atingiu o escore máximo de 4,37 na maioria

do tempo. Em dois momentos a qualidade caiu e o MOS chegou a 3,80, como pode

ser observado no gráfico da Figura 18. Com isso, o MOS médio ficou em 4,34 e o

fator R médio em 90,46. Com base na Tabela 5 apresentada no capítulo 2 deste

trabalho, esse resultado demonstra que os usuários estariam muito satisfeitos com a

qualidade de voz.

usuários estariam muito satisfeitos com a qualidade de voz. Figura 18 - Gráfico do MOS no

Figura 18 - Gráfico do MOS no teste sem VPN

Quando foi executado o teste com o tráfego passando pela VPN, o MOS

também atingiu o escore máximo de 4,37. Porém, ocorreram vários momentos de

queda da qualidade, como pode ser observado no gráfico da Figura 19, onde o MOS

chegou ao escore mínimo de 2,45. A média do MOS e do fator R ficaram abaixo da

média obtida no teste sem VPN. O MOS médio foi de 4,25 e o fator R médio foi de

88,26. Isso resultaria em usuários satisfeitos com a qualidade de voz, de acordo com

a Tabela 5 apresentada no capítulo 2.

com a qualidade de voz, de acordo com a Tabela 5 apresentada no capítulo 2. Figura

Figura 19 - Gráfico do MOS no teste com VPN

46

Quando os dois resultados são sobrepostos em um só gráfico para efeito

comparativo (Figura 20), percebe-se com mais clareza o quanto a qualidade da voz

é degradada quando passa pela VPN.

a qualidade da voz é degradada quando passa pela VPN. Figura 20 - Gráfico do MOS

Figura 20 - Gráfico do MOS com o resultado dos dois testes

O tráfego de voz passando pela VPN contribuiu para o aumento do atraso fixo

de rede e conseqüentemente do atraso fim-a-fim. O atraso fixo de rede passou de

20 ms sem VPN para 25 ms com VPN e o atraso fim-a-fim passou de 61 ms para

65 ms. Observando os dados do atraso fixo de rede na Tabela 9, percebe-se que

ele alcançou um valor máximo de 101 ms com o uso da VPN.

 

Médio

Mínimo

Máximo

Sem VPN

20

ms

18 ms

23 ms

Com VPN

25

ms

19 ms

101 ms

Tabela 9 – Resultados do atraso fixo de rede

Pelo gráfico da Figura 21 percebe-se que esse atraso máximo ocorreu no

mesmo momento que o MOS alcançou o menor valor (2,45) no teste com VPN

(Figura 19), sendo ele o responsável por essa degradação na qualidade da voz

naquele instante.

47

47 Figura 21 – Gráfico do atraso fixo de rede Foi observado também que a perda

Figura 21 – Gráfico do atraso fixo de rede

Foi observado também que a perda de dados só ocorreu quando o tráfego

passou pela VPN, conforme está detalhado na Tabela 9.

 

Bytes

Bytes

Bytes

% Bytes

enviados

recebidos

perdidos

perdidos

pelo

pelo

Linux 1

Linux 2

Sem VPN

1.200.000

1.200.000

0

0,000

Com VPN

1.200.000

1.199.840

160

0,013

Tabela 10 – Resultados da perda de dados

Essa perda de dados ocorreu por volta dos 45 segundos do período de teste,

como pode ser observado na Figura 22. Ela provocou uma pequena degradação na

qualidade de voz, visto que o MOS neste mesmo instante caiu para um valor abaixo

de 4 (Figura 19).

visto que o MOS neste mesmo instante caiu para um valor abaixo de 4 (Figura 19).

Figura 22 – Gráfico da perda de dados

48

6.2

Conclusões

Na implantação de VPN em Linux pôde-se constatar que a escolha da

distribuição Linux e da solução de VPN pode interferir no nível de dificuldade para

colocar a VPN em funcionamento.

No caso da solução de VPN Poptop 1.3.0, versão estável disponível no

período de realização dos testes deste trabalho, é requerida a versão 2.4.3 do

pacote PPP. No Conectiva Linux 10, distribuição escolhida para realização dos

testes deste trabalho, a versão atualizada do PPP é a 2.4.2b3, sendo necessário

portanto conseguir o código fonte do PPP para compilar e instalar em substituição à

versão que acompanha a respectiva distribuição.

No projeto S/WAN, fez-se tentativas com o openswan 2.4.0 e com o

strongswan

2.7.0.

Mesmo

seguindo

todos

os

passos

das

documentações

encontradas e usando diferentes parâmetros de configuração, não se obteve êxito

na criação de uma VPN.

Já a implementação do OpenVPN ocorreu de forma tranqüila. Seguindo as

orientações da documentação existente no site do produto, conseguiu-se colocar

uma VPN em funcionamento na primeira tentativa. Não foi necessária nenhuma

alteração no kernel nem em pacotes da distribuição. Os pacotes necessários ao

funcionamento já estavam disponíveis no Conectiva Linux 10. A única dificuldade foi

identificar o nome dos pacotes necessários.

49

No inicio da pesquisa para este trabalho, pensou-se em usar somente

softwares de código aberto para a realização dos testes. Esta idéia foi abortada

quando se descobriu o nível de complexidade que se teria para aplicar qualquer um

dos métodos de teste da qualidade de voz. Ter encontrado um software como o

IxChariot facilitou a execução dos testes, tanto por ele disponibilizar módulos

agentes para o sistema operacional Linux como pela simplicidade com que os testes

puderam ser executados após a infra-estrutura estar pronta.

Nos experimentos realizados, em que foi submetido tráfego de VoIP sem VPN

e com VPN, foram encontradas dificuldades iniciais de infra-estrutura. As primeiras

tentativas de realização dos testes aconteceram em um ambiente que simulava uma

rede de longa distância, mas foram percebidas falhas no controle do tráfego. Com a

disponibilidade de uma rede de longa distância real, os testes puderam ser

realizados em horário onde o tráfego da respectiva rede era irrelevante.

Os resultados coletados e analisados comprovam que o uso de VPN para

tráfego de Voz sobre IP degrada a qualidade da comunicação. Uma das causas

disso é o overhead que a solução de VPN adiciona aos dados. Porém, a mesma

análise mostra que a degradação não é tão acentuada a ponto de ser totalmente

descartado o uso de VPN em Linux para tráfego de voz. Por ser baseado em uma

análise empírica dos resultados de três testes, esse parecer não deve ser tomado

como uma verdade absoluta.

50

Mesmo assim, acredita-se ter alcançado o resultado esperado com este

trabalho em razão dele apresentar subsídios que auxiliam na decisão de adotar ou

não uma solução de VPN para tráfego de Voz sobre IP. Caso essa solução de VPN

adotada seja em Linux, a configuração do OpenVPN usada no ambiente de testes

pode ser facilmente implantada em qualquer empresa que necessite interligar pontos

remotos.

6.3

Sugestões para Trabalhos Futuros

Para trabalhos futuros é sugerido o mesmo teste feito neste trabalho, porém

com diferentes soluções de VPN em Linux. Com isso pode-se chegar, por exemplo,

a uma identificação de qual a melhor solução de VPN em Linux para tráfego de Voz

sobre IP.

Também é sugerida a realização dos testes com diferentes codificadores de

voz, visando identificar qual deles sofre menor impacto na qualidade da voz quando

o tráfego passa através de uma VPN.

Uma outra possibilidade de trabalho futuro é o estudo de soluções de

qualidade de serviço (Quality of Service – QoS) para tráfego de Voz sobre IP em

VPN sob Linux.

51

7. REFERÊNCIAS BIBLIOGRÁFICAS

CARDOSO, André. As 100 Empresas mais ligadas do Brasil: Os hábitos

51-58,

eficazes dos donos Abr 2005

de TI. INFO Exame, São Paulo, ano 20,

n 229,

p

CARVALHO, Leandro S. G.; MOTA, Edjair S.; QUEIROZ, Juliana M. Análise comparativa de padrões para medida de qualidade de voz, in: Congresso Nacional de Tecnologia da Informação - SUCESU’2003, 2003, Salvador. Anais

eletrônicos

em

<http://www.dcc.ufam.edu.br/~labvoip/docs/publicacoes/Leandro/SUCESU03_a

nalise_comp.pdf >. Acessado em: 12 maio 2006

Salvador,

2003.

Disponível

DAVIDSON, Jonathan; JAMES, Peters. Voice Over IP Fundamentals - Indianápolis: Cisco Press, 2000

DELOITTE Touche Tohmatsu - Pesquisa da Deloitte indica que dois terços das maiores companhias do mundo terão implantado serviços de voz pela internet (VoIP) até o final de 2005 - 2004 – Disponível em

<http://www.deloitte.com/dtt/press_release/0,1014,sid%253D55429%2526cid%2

53D77778,00.html> acessado em: 7 maio 2006

DIERKS, T.; ALLEN, C. The TLS Protocol Version 1.0, RFC 2246, Janeiro

1999 – Disponível em <http://www.ietf.org/rfc/rfc2246.txt>. Acessado em: 15 maio

2006

GLEESON, B. et al, A Framework for IP Based Virtual Private Networks, RFC 2764, Fevereiro 2000 – Disponível em <http://www.ietf.org/rfc/rfc2764.txt>. Acessado em: 30 abr. 2006

GILMORE, Jonh. FreeS/WAN: Securing the Internet against Wiretapping.

[S.l.]: 2003. Disponível em: <http://www.freeswan.org/history.html>. Acessado em

20 maio 2006

GREENE, Tim. Grandes empresas lideram o uso de VoIP – Disponível em

<http://idgnow.uol.com.br/telecom/2006/05/18/idgnoticia.2006-05-

18.0065292415>. Acessado em: 31 maio 2006

Point-to-Point Tunneling Protocol (PPTP), RFC 2637,

Julho 1999 – Disponível em <http://www.ietf.org/rfc/rfc2637.txt >. Acessado em:

HAMZEH, K. et al,

52

ITU-T Recommendation G.107, The E-Model, a computacional model for use in transmission plan, dezembro 1998

ITU-T Recommendation G.114, One way transmission time, fevereiro 1996

ITU-T Recommendation G.711, Pulse Code Modulation (PCM) of Voice Frequencies, 1972

ITU-T Recommendation P.800, Methods for subjective determination of transmission quality, agosto 1996

ITU-T Recommendation P.862, Perceptual evaluation of speech quality (PESQ): An objective method for end-to-end speech quality assessment of narrowband telephone networks and speech codecs, fevereiro 2001

IXIA, IxChariot User Guide, Release 5.40. [S.l.]: Ixia, 1988-2004, 1 CD-ROM

KENT, S.; ATKINSON, R., Security Architecture for the Internet Protocol, RFC 2401, Novembro 1998 – Disponível em <http://www.ietf.org/rfc/rfc2401.txt>. Acessado em: 12 maio 2006

KOLESNIKOV,

Oleg;

HATCH,

Brian;

CARASIK-HENMI,

Anne; Building

Linux Virtual Private Networks. New Riders 2002

KRANYANSKY, Maxim. Universal TUN/TAP driver – FAQ. [S.l.]: 2001.

Disponível em <http://vtun.sourceforge.net/tun/faq.html>. Acessado em 20 maio

2006.

LEEUW, Jacco de. Using a Linux L2TP/IPsec VPN Server. [S.l.]: 2006. Disponível em: <http://www.jacco2.dds.nl/networking/freeswan-l2tp.html> . Acessado em 20 maio 2006

MASON, Andrew. Cisco Secure Virtual Networks - Cisco Press, 2001

MICROSOFT White Paper,

<http://www.microsoft.com/technet/prodtechnol/windows2000serv/plan/vpnove

rview.mspx>. Acessado em: 30 abr. 2006

CORPORATION.

Setembro

Virtual

2001

Private

Networking:

Overview,

em

Disponível

OETIKER, Tobias. MRTG – Multi Router Traffic Grapher. [S.l.]: 2006. Disponível em: <http://oss.oetiker.ch/mrtg/doc/mrtg.en.html>. Acessado em 21 maio 2006

em

<http://www.windowsecurity.com/articles/Secure_Socket_Layer.html> acessado em: 15 maio 2006

ONYSZKO,

Tomasz.

Secure

Socket

Layer

2004

Disponível

OPENVPN

SOLUTIONS

LLC.

OpenVPN,

Disponível

em:

<http://www.openvpn.net>. Acessado em 18 maio 2006

53

RESENDE, Edmar R. S de. Segurança no Acesso Remoto VPN. 2004. Tese (Mestrado em Ciência da Computação) – Instituto de Computação – UNICAMP, Campinas.

SANT’ANNA, Giovani F., Conectividade virtual segura e de baixo custo com Linux. 2003. Tese (Mestrado em Engenharia de Computação) – Instituto de Pesquisas Tecnológicas – IPT, São Paulo.

SCOTT, Charlie; WOLFE, Paul; ERWIN, Mike. Virtual Private Networks, Second Edition, O’Reilly, 1999

SIMPSON,

W.,

The

Point-to-Point

Protocol,

RFC 1661,

Julho

1994

Disponível em <http://www.ietf.org/rfc/rfc1661.txt>. Acessado em: 1 mar. 2006

STALLINGS, William. Operating Systems: Internals and Design Principles, Fifth Edition - Prentice Hall, 2005

SZIGETI, Tim; HATTINGH, Cristina. End-to-End QoS Network Design, Indianapolis: Cisco Press, 2005

TANEMBAUM, Andrew S. Computer Networks – Fourth Edtion, Prentice Hall, 2003

TOWNSLEY, W. et al, Layer Two Tunneling Protocol “L2TP”, RFC 2661, Agosto 1999 – Disponível em <http://www.ietf.org/rfc/rfc2661.txt>. Acessado em:

14 mai. 2006

VPNC Virtual Private Network Consortium - VPN Technologies: Definitions and Requirements – Março 2006 – Disponível em <http://www.vpnc.org/vpn- technologies.html>. Acessado em: 01 maio 2006

WALDIE, Robert. Poptop – The PPTP Server for Linux, 2006 – Disponível em <http://www.poptop.org>. Acessado em: 18 maio 2006

WALLINGFORD, Ted. Switching to VoIP. [S.l.]: O’Reilly, 2005

XELERANCE

CORPORATION.

OpenSwan.

[S.l.]:

2006.

Disponível

em

<http://www.openswan.org>. Acessado em: 18 maio 2006

54

8. BIBLIOGRAFIA

HARKINS, D.; CARREL, D., The Internet Key Exchange (IKE), RFC 2409, Novembro 1998 – Disponível em <http://www.ietf.org/rfc/rfc2409.txt>. Acessado em: 12 maio 2006

ITU-T Recommendation G.726, 40, 32, 24, 16 kbits/s Adaptive Diferencial Pulse Code Modulation (ADPCM), 1990

ITU-T Recommendation P.830, Subjective Performance assessment of telephone-band and wideband digital codecs, fevereiro 1996

KENT, S.; ATKINSON, R., IP Authentication Header, RFC 2402, Novembro

1998

– Disponível em <http://www.ietf.org/rfc/rfc2402.txt>. Acessado em: 12 maio

2006

 

,

IP Encapsulation Security Payload (ESP), RFC 2406, Novembro

1998

– Disponível em <http://www.ietf.org/rfc/rfc2406.txt>. Acessado em: 12 maio

2006

RODRIGUES, Paulo

H. de A

da fala em sistemas de comunicação baseados em voz sobre IP, Anais do 22o. Simpósio Brasileiro de Redes de Computadores, 2004, Gramado. (14pgs).

MOTA, Edjair de S., Utilização do Modelo E para avaliação da qualidade

LUSTOSA, Leandro C. G

CARVALHO. Leandro S. G

MADSON, C.; DORASWAMY, N., The ESP DES-CBC Cipher Algorithm With Explicit IV, RFC 2405, Novembro 1998 – Disponível em <http://www.ietf.org/rfc/rfc2405.txt>. Acessado em: 12 maio 2006

MADSON, C.; GLEN, R., The Use of HMAC-MD5-96 within ESP and AH, RFC 2403, Novembro 1998 – Disponível em <http://www.ietf.org/rfc/rfc2403.txt>. Acessado em: 12 maio 2006

, The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404,

Novembro 1998 – Disponível em <http://www.ietf.org/rfc/rfc2404.txt>. Acessado

em: 12 maio 2006

MAGRO, Júlio César. Estudo da Qualidade de Voz em Redes IP. 2005. Dissertação (Mestrado em Engenharia Elétrica) Faculdade de Engenharia Elétrica e de Computação – FEEC/UNICAMP, Campinas-SP

55

MAUGHAN, D. et al, Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, Novembro 1998 – Disponível em <http://www.ietf.org/rfc/rfc2408.txt>. Acessado em: 12 maio 2006

MENCARI, Mirele de Almeida. Proposta de Metodologia de Projeto de Redes VPN de Voz, 2003. Dissertação (Mestrado em Engenharia Elétrica) - Universidade de Brasília

PIPER, D., The Internet IP Security Domain of Interpretation for ISAKMP,