AVALIAO DA QUALIDADE DE SERVIO DAS VPN

IP MPLS PARA REDES DE NOVA GERAO (NGN)

Ado Boava
Mestre em Engenharia de Computao pela UNICAMP. MBA em Administrao e Marketing pela FGV.
Especializao em Redes de Comunicao pelo INATEL. Trabalha h 15 anos na Brasil Telecom em
solues de Redes de Comunicaes. Atualmente est trabalhando em sua tese de doutorado no departamento
de comunicaes da Faculdade de Engenharia Eltrica e Computao da UNICAMP.
ado@brasiltelecom.com.br
Yuzo Iano
Doutor em Engenharia Eltrica. Professor Associado do Departamento de Comunicao da Faculdade de
Engenharia Eltrica de Computao da UNICAMP. Coordenador do Laboratrio de Comunicaes Visuais
do Departamento de Comunicaes da Faculdade de Engenharia Eltrica e de Computao da Unicamp
(LCV/Decom/Feec/Unicamp).
yuzo@decom.fee.unicamp.br

Resumo - As tecnologias VPN/MPLS e DiffServ tm sido propostas para o provimento

de qualidade de servio(QoS) para a prxima gerao das VPNs. Este artigo apresenta os
resultados da avalio da QoS baseada nestas tecnologias. O trabalho proposto utiliza um
ambiente de teste desenvolvido para este artigo com o objetivo de validar a implementao
de VPNs MPLS com DiffServ. Foram realizados testes voltados para a gerao de dados
referentes a qualidade de servio. Esses dados permitiram a realizao de anlises do
desempenho das VPNs MPLS. O artigo apresenta tambm a implementao da RFC 2547.
De forma geral, o artigo capaz de representar o desenvolvimento e a avaliao de VPNs
MPLS para vrias classes com qualidade de servio fim a fim, as quais transportam
trfegos de diversas aplicaes: trfego melhor esforo (best effort), trfego com
prioridades (AF1, AF2, AF3, AF4) e trfego de voz (EF).
Palavras-chave - VPN, MPLS, QoS, DiffServ e CoS
1.

INTRODUO

Observa-se nos ltimos anos um aumento das exigncias por servios de comunicao
de dados capazes de integrar vrias mdias como dados, voz e imagem com qualidade de
servio (QoS)[2].
Constata-se um crescente interesse pelas aplicaes multimdia distribudas (vdeoconferncia, TV Digital, telemedicina, telefonia IP, etc.) na utilizao das redes IP. Essas

aplicaes caracterizam-se, principalmente, pelo emprego de diversos tipos de mdia que

impem requisitos distintos de QoS ao sistema de comunicao. Como exemplos de
atributos de QoS podemos destacar: retardo mximo, variao mxima do atraso, taxa de
transmisso, taxa de perda, disponibilidade, etc. Entretanto, as VPNs IP tradicionais, com
seu modelo de servios do tipo melhor esforo, comeam a dar sinais de estrangulamento.
Uma das conseqncias da adoo desse modelo que todo o trfego tratado de maneira
uniforme, sem nenhum tipo de diferenciao ou priorizao. Contudo, nem todos os tipos
de trfego e transaes so equivalentes ou tm a mesma importncia para os usurios.
desejvel que algumas aplicaes recebam tratamento diferenciado segundo suas demandas
especficas, o que no possvel no modelo atual. Por essa razo, pesquisas tm sido
conduzidas nesse sentido, dando origem a vrias arquiteturas de servios que buscam
integrar as tecnologias VPN MPLS[4] e DiffServ[1]. So muitos os desafios relacionados
ao projeto de redes VPN baseadas na tecnologia MPLS com qualidade de servio (QoS)
fim a fim.
Sendo assim, neste artigo ser apresentado o resultado de estudo e testes sobre a
implementao de QoS em redes de nova gereo com o ncleo MPLS .

2.1.

2. PRINCIPAIS CARACTERSTICAS
VPN MPLS RFC 2547[4,5,8]

Redes Virtuais Privadas MPLS na RFC-2547bis definem um mecanismo pelo quais os

provedores de servio podem usar seu backbone para prover servio de VPN para seus
clientes. A RFC-2547bis[8] tambm conhecida como VPN BGP-MPLS porque o BGP o
protocolo utilizado para distribuio da informao de roteamento das VPNs e pela
utilizao do MPLS no estabelecimento dos circuitos virtuais e encaminhamento do
trfego.
Um provedor pode gerenciar mltiplas VPNs desde que as regras estejam habilitadas
para manter separadas as rotas das diferentes VPNs.
A conexo de enlace entre os roteadores CE e PE pode ser uma conexo remota atravs
de Frame Relay ou ATM, ou ainda, um enlace Ethernet. As redes dos clientes trocam rotas
com provedores de servios (CE para PE), usando rotas estticas ou via RIP, OSPF ou EBGP.
Quando o roteador PE recebe a rota atualizada criada uma tabela de roteamento e as
informaes de alcanabilidade so encaminhadas para cada ponto da VPN conectada no
roteador.
Os roteadores PEs estabelecem sesses MP-iBGP para trocar rotas de clientes. O
trfego da rede do provedor passa atravs do LSP (Label Switched Path) pr-estabelecido
atravs dos protocolos de sinalizao LDP ou RSVP-TE. O roteador PE adiciona dois
rtulos como prefixos para cada pacote do trfego IP do cliente. O rtulo mais externo
identifica o prximo salto ao longo do LSP do provedor de rede, enquanto o rtulo mais
interno identifica a VPN particular do cliente, conectada no roteador de destino. A
informao do rtulo trocada durante a sesso de configurao MP-iBGP.

Os principais objetivos da RFC 2547bis so:

Oferecer servios simples para os usurios com todo o potencial do roteamento IP;
Oferecer servio com grande escalabilidade e flexibilidade;
Permitir regras que so usadas para criar uma VPN que ser implementada pelo
provedor do servio, de forma independente ou trabalhando junto com o cliente;
Permitir ao provedor de servio a entrega de um servio de valor adicionado que
possa fidelizar seus clientes.
2.1.1. COMPONENTES DA RFC
No contexto da RFC 2547bis, uma VPN uma coleo de regras para controle da
conectividade entre um conjunto de redes. Uma rede de cliente conectada pelo provedor
do servio por uma ou mais portas, sendo que o provedor de servio associa cada porta com
uma tabela de roteamento VPN. Na RFC 2574bis, a tabela de roteamento VPN chamada
VPN Routing and Forwarding (VRF). A figura 1 ilustra os blocos fundamentais para a
VPN BGP/MPLS:

Figura 1 - Componente da VPN MPLS

Customer Edge Devices (CE) Equipamento de borda do cliente

Um customer edge (CE) prov acesso do cliente at o provedor de servio de rede.

Tipicamente, o equipamento CE um roteador IP que estabelece uma conexo diretamente
com o roteador PE. Depois de estabelecida a conexo, o roteador CE anuncia as rotas dos
pontos da VPN local para o roteador PE e aprende as rotas remotas da VPN.

Provider Edge Routers (PE) Equipamento de borda do provedor

Os roteadores PEs trocam informao de roteamento com os roteadores CEs atravs de

roteamento esttico, RIPv2, OSPF ou eBGP. Esse modelo de VPN reala a escalabilidade
da RFC 2574bis porque elimina a necessidade dos roteadores PEs manterem rotas VPNs
com todos os PEs do Provedor de Servio.
Cada roteador PE mantm uma VRF para cada ponto conectado diretamente. Observase que mltiplas interfaces do roteador PE podem ser associadas com uma nica VRF se
todos os pontos de acesso participam da mesma VPN.
Aps aprender as rotas das VPNs locais dos roteadores CEs, um roteador PE troca
informao de roteamento com os outros PEs atravs do BGP (conhecida como iBGP,

conforme figura 1.1a). Roteadores PEs podem manter sesses IBGP para rotas refletidas
(figura 1.1b) como uma alternativa para uma sesso full mesh (todos conversam com
todos).

Figura 2 Router Reflector

Finalmente, quando se utiliza o MPLS para encaminhar o trfego de dados das VPNs
por meio do backbone do provedor, os roteadores PEs de ingresso e egresso funcionam
como LSRs de ingresso e egresso respectivamente.

Provider Routers (P)

Um Router Provider(P) um roteador na rede do provedor que no troca informao

diretamente com o equipamento CE. A funo dos roteadores Ps como transporte MPLS
encaminhar trfego de dados para os roteadores PEs, desde que o trfego seja encaminhado
por meio do backbone MPLS, usando duas camadas da pilha de rtulo (label stack). Os
roteadores Ps so utilizados para manter rotas para os roteadores PEs; eles no so
necessrios para manter informao de roteamento especfico para cada acesso do cliente.

Tabela de Roteamento e Encaminhamento (VRF) da VPN

Um conceito chave na arquitetura VPN BGP/MPLS o elemento chamado de tabela de

Encaminhamento e Roteamento dos roteadores PE. A VRF uma tabela de
encaminhamento e roteamento para cada VPN dentro dos roteadores PEs. Uma VRF
privada acessvel unicamente pelas interfaces que fazem parte da VPN correspondente.
Todos os pontos conectados no roteador PE devem fazer parte de uma VRF. Todas as
informaes das VPNs so refletidas na VRF e os pacotes que viajam atravs daquele ponto
sero roteados e encaminhados com base unicamente na informao encontrada na VRF
correspondente.
2.2.

QoS

Entre as alternativas disponveis para oferecer qualidade de servio s VPNs MPLS,

temos atualmente duas arquiteturas em uso:

Servios Integrados IntServ [13]

Servios Diferenciados - DiffServ [14]

A arquitetura IntServ apresenta problemas de escalabilidade, limitando-se a redes de

pequeno a mdio porte. DiffServ, por outro lado, provou ser bastante escalvel pois a maior

parte do trabalho feita na borda e, consequentemente, no precisa manter qualquer estado

de microfluxo no ncleo como no caso da arquitetura IntServ.
A caracterstica aleatria da chegada de fluxos em diferentes classes de servio obriga a
utilizao de alguma tcnica para fornecimento da QoS. As principais tcnicas so:
provisionamento em excesso dos recursos e provisionamento dinmico. A grande vantagem
do provisionamento em excesso a facilidade de implantao, pois aproveita a infraestrutura existente, apenas aumentando a taxa de transmisso ou a capacidade de
armazenamento nos dispositivos de comutao. A caracterstica dessa tcnica que
normalmente no h classes de servios diferentes e todos os fluxos desfrutam do mesmo
recurso e QoS. A principal desvantagem que manter um canal de comunicao com
capacidade acima da demanda produz um aumento de custo, induzindo maiores tarifas na
prestao do servio.
O aprovisionamento dinmico consiste em utilizar canais de comunicao compatveis
com a demanda e executar mecanismos de reconfigurao que ofeream a QoS desejada
para determinados fluxos. A grande vantagem que h um aproveitamento maior da
capacidade da rede atravs do oferecimento de um servio de melhor qualidade mantendo a
infra-estrutura dimensionada de acordo com a demanda. Assim, possvel dizer que o
aprovisionamento dinmico pode oferecer QoS com um custo menor. A desvantagem desse
mecanismo que exige alterao nos equipamentos de rede, alm de introduzir uma
complexidade adicional.
Em virtude da complexidade dos mecanismos de aprovisionamento dinmico e
principalmente em funo do excesso de banda em seus backbone, a maioria das
operadoras tem preferido superdimensionar os recursos para obter a QoS desejada. Esse
procedimento, no entanto, apresenta um custo muito alto, tanto pela capacidade no
utilizada na maior parte do tempo (deve-se aprovisionar pelo pico) como pela necessidade
de planejar o crescimento, j que construir infra-estrutura de telecomunicaes exige uma
estimativa de trfego futuro, que tende a ser imprecisa.
Com o advento das redes de acesso banda larga xDSL, os backbones das operadoras
esto encontrando dificuldades para manter os nveis de servios para seus clientes usando
apenas superprovisionamento. Tambm a necessidade de oferecer servios com menor
custo e preos mais competitivos esto levando as operadoras a implementarem
aprovisionamento dinmico.
A utilizao de mecanismos de aprovisionamento dinmico no suficiente para
garantir a qualidade de servio em toda a VPN. necessrio executar o controle de
aprovisionamento, bem como um gerenciamento sobre todo o domnio da VPN, isto , em
todo o conjunto de equipamentos da operadora e do cliente (CE a CE).
A diferenciao de Servios (DiffServ) uma proposta de arquitetura para oferecer
recursos de QoS em todo o conjunto de equipamentos de CE a CE sem o problema da
escalabilidade. Nesse caso, os fluxos so agregados em classes de servio com um padro
de QoS especfico. Com uma quantidade de classes limitada, a necessidade de recursos
computacionais nos roteadores reduzida pela menor quantidade de estados a tratar.

Nos backbones onde a operadora deseja disponibilizar solues de VPN BGP/MPLS

com classes diferentes de servio para os seus clientes recomenda-se a utilizao de
aprovisionamento dinmico com DiffServ. No prximo tpicos sero realizados testes do
servio VPN com QoS baseados na arquitetura DiffServ.
A identificao da classe de servio feita pela marcao no campo DS Servios
Diferencial, antigo campo TOS (Tipo de Servio) no cabealho IP. O campo DS contm
um valor chamado codepoint que associado a cada classe de servio. O tratamento que
uma determinada classe recebe depende de um conjunto de regras aplicadas a essa
agregao, que inclui formas de classificao, escalonamento e tratamento de fila. Esse
conjunto de regras chamado PHB Per Hop Behavior, isto , comportamento por n. Um
operador de rede que oferece servio DiffServ tem um contrato de servio SLA com o
usurio e deve cumprir parmetros de QoS para o trfego do usurio que cruza a VPN, isto
, parmetros como retardo, variao do retardo (jitter) e descarte.
3. Arquitetura DiffServ[14]
Para evitar o problema de escalabilidade da arquitetura IntServ, na qual os
roteadores de ncleo no conseguem tratar uma grande quantidade de fluxos, a arquitetura
DiffServ foi dividida em dois tipos de roteadores de acordo com a sua posio no domnio:
de ncleo ou de borda. Os roteadores de borda ficam na fronteira do domnio e tm a
funo de fazer a comunicao com roteadores de outras operadoras de backbone ou
clientes. Os roteadores de ncleos encontram-se todos no ncleo da rede, sem contato com
outros backbones de operadoras ou clientes, e onde o trfego e a quantidade de fluxos so
maiores devido agregao dos trfegos originrios de vrios roteadores de borda. A figura
3 mostra esquematicamente a arquitetura de um domnio DiffServ.
Na arquitetura DiffServ, os roteadores de borda realizam toda a complexidade de
classificao, marcao, suavizao e policiamento. Como esses roteadores tratam uma
quantidade menor de fluxos, essas funes, computacionalmente intensas, podero ser
realizadas sem prejuzo da escalabilidade.

Figura 3 Arquitetura DiffServ

3.1.

TESTE DE QoS (PE e CE)

Para os testes de QoS no CE e PE foram utilizados quatro cenrios (tabela 1). Nesse
artigo ser apresentado somente os resultados dos testes de QoS no CE para evitar que o
artigo ficasse excessivamente longo. Os testes de QoS no PE ser apresentado em outro
artigo
Cenrio 1: Voz (EF) e Dados Best Effort (BE), com a soma das bandas geradas (30 kbps +
120 kbps) para cada classe menor que a velocidade do acesso (256 kbps).
Cenrio 2: Voz (EF) e Dados Best Effort (BE), com a soma das bandas geradas para cada
classe ( 30 kbps + 300 kbps) maior que a velocidade de acesso (256 kbps).
Cenrio 3: Voz (EF), Dados Best Effort (BE), Misso Critica (AF11) e Suporte a Negcio
(AF31), com a soma das bandas geradas ( 30 kbps + 50 kbps + 30 kbps + 20 kbps) menor
que a velocidade de acesso (256 kbps).
Cenrio 4: Voz (EF), Dados Best Effort (BE), Misso Critica (AF11) e Suporte a Negcio
(AF31), com a soma das bandas geradas ( 30 kbps + 50 kbps + 30 kbps + 200 kbps) maior
que a velocidade de acesso (256 Kbps).
A razo de realizar os testes de QoS tambm no CE, porque as VPN MPLS
oferecidas atualmente pelos principais provedores os pacotes so classificados a partir do
CE, e no como as VPNs MPLS tradicionais, onde os pacotes so classificados somente no
PE.
Propsito: Avaliar o comportamento dos parmetros de QoS para as classes de
servio Voz (EF), Misso Crtica (AF11), Suporte ao Negcio (AF31) e Dados Melhor
Esforo (BE), implementados no CE cisco 827, na presena de uma demanda de trfego
superior banda nominal disponvel no acesso. Ou seja, o teste deve mostrar que os pacotes
classificados como EF tenham prioridade em relao s classes AF e BE; que AF11 tenha
prioridade em relao ao AF31 e BE; e finalmente que AF31 seja prioritrio em relao aos
pacotes BE.
Para esses testes foram utilizados os seguintes componentes:
Gerador de trfego
Nesse tipo de teste especfico, usado o Iperf (www.iperf.com), instalado nas
mquinas geradoras e receptoras.
Unidades de Capturas

As unidades de capturas sero os monitores dos 2 computadores, onde sero gerados

o trfego e os arquivos com todos os logs capturados.

Figura 4 Topologia para o teste

Tabela 1 Classes de Servios

Procedimento:
Gerar fluxos de trfego para cada classe de servio de acordo com a tabela 1. Nessa
tabela, a banda configurada refere-se ao CE; trfegos gerados, tamanhos de pacote,
protocolo e porta so parmetros de entrada do Iperf (gerador).
Dados a serem registrados:

Valores dos parmetros de QoS Vazo, Atraso, Perdas de Pacotes e Jitter.

Ser mostrado, a ttulo de exemplo, o procedimento para capturar os dados da classe

voz no caso do cenrio 1. Para os demais cenrios e classes foram realizados os mesmos
procedimentos, sendo plotados somente os grficos.
Ex:

Configurar o servidor iperf para o fluxo UDP no computador de Porto Alegre.

Receptor: Iperf s u p5001 b54k

Configurar o cliente iperf para o fluxo UDP no computador de Braslia Gerador: Iperf
c10.200.0.2 u p5001 b54k
Procedimento:
Gerar fluxos de trfego para cada classe de servio de acordo com a tabela 1. Nessa
tabela, a banda configurada refere-se ao CE; trfegos gerados, tamanhos de pacote,
protocolo e porta so parmetros de entrada do Iperf (gerador).
Dados a serem registrados:

Valores dos parmetros de QoS Vazo, Atraso, Perdas de Pacotes e Jitter.

Ser mostrado, a ttulo de exemplo, o procedimento para capturar os dados da classe

voz no caso do Cenrio 1. Para os demais cenrios e classes foram realizados os mesmos
procedimentos, sendo plotados somente os grficos.
Ex:

Configurar o servidor iperf para o fluxo UDP no computador de Porto Alegre.

Receptor: Iperf s u p5001 b54k

Configurar o cliente iperf para o fluxo UDP no computador de Braslia Gerador: Iperf
c10.200.0.2 u p5001 b54k
Cenrio 1:
Teste de QoS no CE para o cenrio 1 QoS2.1

Resultado obtido para o tamanho dos pacotes de dados de 500Kb

QoS.2.1.1 - Jitter

QoS.2.1.1 - BandWidht

25,00
140

15,00

Dados (BE)

10,00

Voz (EF)

5,00

BandWidht (Kbps)

Jitter(ms)

20,00

120
100
80

Dados (BE)

60

Voz (EF)

40
20

0,00

Tempo

Tempo

Figura 5 - Jitter x Tempo

Figura 6 - BandWidht x Tempo

Resultado obtido para o tamanho dos pacotes de dados de 1200 byte

QOS.2.1.1 - Bandwidht

QoS.2.1.1 - Jitter
140

35

120

Jitter (ms)

30
25

Dados (BE)

20

Voz (EF)

15
10

Bandwidht (Kbps)

40

100
80

Dados (BE)

60

Voz (EF)

40
20

0
Tempo (s)
Figura 7 - Jitter x Tempo

Tempo (s)
Figura 8 - BandWidht x Tempo

Concluso do cenrio 1:
Os valores de vazo, atraso, jitter e perda de pacotes mantiveram-se em nveis normais, ou seja, em
condies sem congestionamento o desempenho das aplicaes no prejudicado. Condies sem
congestionamento aquela em que a soma dos trfegos gerados (30 kbps + 120 kbps) pelas aplicaes
menor que a soma no acesso (256kbps). Os Valores de pacotes perdidos (loss) no foram apresentados
nesse cenrio, pois no houve perda de pacotes.
Cenrio 2:
Teste de QoS2.1 no CE para o cenrio 2

Resultado obtido para o tamanho dos pacotes de dados de 500 bytes

QoS.2.1.2 - Jitter

QoS.2.1.2 - Bandwidht

40,00
35,00
30,00
25,00
20,00
15,00
10,00
5,00
0,00

160

Dados
Voz

Bandwidht (Kbps)

Jitter(ms)

180
140
120
100

Dados

80

Voz

60
40
20
0

Tempo (s)

Tempo (s)
Figura 11 - Bandwidht x Tempo

Figura 9 - Jitter x Tempo

QoS.2.1.2 - Loss
70
60

Loss (%)

50
40

Dados

30

Voz

20
10
0

Tempo (s)
Figura 10 - Loss x Tempo

Resultado obtido para o tamanho dos pacotes de dados de 1200 bytes

QoS.2.1.2 - Loss

60,00

60

50,00

50

40,00
Dados

30,00

Voz

20,00

40
Dados

30

Voz

20
10

10,00

0,00
Tempo (s)
Figura 12 - Jitter x Tempo

QoS.2.1.2 - Bandwidht
250

Bandwidht (Kbps)

Loss (%)

Jitter (ms)

QoS.2.1.2 - Jitter

200
150
Dados
Voz

100
50
0
Tempo (s)
Figura 14 - Bandwidht x Tempo

Tempo (s)
Figura 13 - Loss x Tempo

Concluso do Cenrio 2:
Para pacotes de dados de 500 bytes, os valores de vazo, atraso, jitter e perda de pacotes se mantiveram
em nveis aceitveis para a classe VOZ (EF) e Dados mesmo numa situao de congestionamento.
Considera-se que uma situao de congestionamento aquela onde o trfego gerado pelas aplicaes (30
kbps + 300 kbps) maior que a velocidade de acesso (256 kbps).
Para pacotes de dados de 1200 bytes, nota-se uma diminuio da vazo, a ocorrncia de perdas de
pacotes e um aumento no jitter para a classe VOZ. Este fato conseqncia do tempo que o pacote
(pequeno) de voz (60 bytes) tem que aguardar na fila enquanto um pacote (grande) de dados (1200 bytes)
transmitido. Recomenda-se fortemente o uso de mecanismos de LFI (Fragmentao e Intercalao da
Camada de Enlace) nos acessos para manter os valores de jitter em nveis que no prejudiquem a qualidade
da comunicao de voz. Deve ser feito um ajuste fino no tamanho da fila de VOZ no CE e no PE para se
reduzir as perdas de pacotes.
Cenrio 3

Resultado obtido para o tamanho dos pacotes de dados de 500 bytes

QoS.2.1.3 - Jitter

QoS.2.1.3 - Bandwidht

25

60

Dados (BE)

15

S_N (AF31)
VOZ (EF)

10

M_C (AF11)

5
0

Bandwidht (Kbps)

Jotter (ms)

20

50

S_N (AF31)

30

VOZ (EF)

20

M_C (AF11)

10
0

Tempo (s)
Figura 15 - Jitter x Tempo

Dados (BE)

40

Tempo (s)
Figura 16 - Bandwidht x Tempo

Resultado obtido para o tamanho dos pacotes de dados de 1200 bytes

QoS.2.1.3 - Jitter

QoS.2.1.3 - Loss

40,00
3,5

35,00

25,00

Dados_BE

20,00

S_N (AF31)

15,00

VOZ (EF)
M_C (AF11)

10,00

2,5

Dados (BE)

S_N (AF31)
VOZ (EF)

1,5

M_C (AF11)

1
0,5

5,00
0,00

Loss (%)

Jitter (ms)

30,00

Tempo (s)
Figura 17 - Jitter x Tempo

0
Tempo (s)
Figura 19 - Loss x Tempo

QoS.2.1.3 - Bandwidht

Bandwidht (Kbps)

60
50
Dados (BE)

40

S_N (AF31)

30

VOZ (EF)

20

M_C (AF11)

10
0

Tempo (s)

Figura 18 - Bandwidht

Concluso do cenrio 3:
Os valores de vazo, atraso, jitter e perda de pacotes se mantiveram em nveis normais para essa
situao sem congestionamento. O jitter para a classe voz no ultrapassou os 15ms para o tamanho do
pacote de 500 bytes e 20ms para 1200 bytes, esses valores so considerados muito bons para voz, na prtica
o valor de at 30ms considerado excelente. A bandwidht para os tamanhos de pacotes de 500 e 1200
bytes mantiveram na mdia os mesmos valores do trfego gerado. As perdas de pacotes foram mnimas
para o tamanho de pacotes de 1200bytes, mas nada que possa preocupar.
Cenrio 4

Resultado obtido para o tamanho dos pacotes de dados de 500 bytes

QoS.2.1.4 - Jitter

QoS.2.1.4 - Loss

120,00
80
70
60

80,00

Dados (BE)
S_N (AF31)

60,00

VOZ (EF)

40,00

M_C (AF11)

20,00

S_N (AF31)

40

VOZ (EF)

30

M_C (AF11)

20
0

Tempo (s)
Figura 20 - Jitter x Tempo

QoS.2.1.4 - Bandwidht
80

Bandwidht (Kbps)

Dados (BE)

50

10

0,00

70
60
50

Dados (BE)

40

S_N (AF31)

30

VOZ (EF)
M_C (AF11)

20
10
0

Loss (%)

Jitter (ms)

100,00

Tempo (s)
Figura 22 - Bandwidht x Tempo

Tempo (s)
Figura 21 - Loss x Tempo

Resultado obtido para o tamanho dos pacotes de dados de 1200 bytes

QoS.2.1.4 - Jitter

QoS.2.1.4 - Loss

250,00

Dados (BE)

150,00

S_N (AF31)
VOZ (EF)

100,00

M_C (AF11)

50,00
0,00

Loss (%)

Jitter (ms)

200,00

100
90
80
70
60
50
40
30
20
10
0

Tempo (s)
Figura 23 - Jitter x Tempo

Dados (BE)
S_N (AF31)
VOZ (EF)
M_C (AF11)

Tempo (s)
Figura 24 - Loss x Tempo

QoS.2.1.4 - Bandwidht

Bandwidht (Kbps)

250
200
Dados (BE)

150

S_N (AF31)
VOZ (EF)

100

M_C (AF11)

50
0
Tempo (s)
Figura 25 - Bandwidht x Tempo

Concluso do Cenrio 4:
Para pacotes de dados de 500 bytes, os valores de vazo, atraso, jitter e perda de pacotes se mantiveram
em nveis aceitveis para as classes, inclusive VOZ, mesmo numa situao de congestionamento. Ocorreu
um aumento do RTT em relao ao cenrio 3, pois o cenrio 4 representa uma situao de
congestionamento.
Para pacotes de dados de 1200 bytes, nota-se uma diminuio da vazo, a ocorrncia de perdas de
pacotes e um aumento no jitter para a classe VOZ. Este fato conseqncia do tempo que o pacote
(pequeno) de voz (60 bytes) tem que aguardar na fila enquanto um pacote (grande) de dados (1200 bytes)
transmitido. Recomenda-se fortemente o uso de mecanismos de LFI (Link-Layer Fragmentation and
Interlaeaving) nos acessos para manter os valores de jitter em nveis que no prejudiquem a qualidade da
comunicao de voz. Tambm deve ser feito um ajuste fino no tamanho da fila de VOZ no CE e no PE para
se reduzir as perdas de pacotes. Ou seja, o resultado desse cenrio mostra que necessrio alm de
DiffServ alguns mecanismos extra para oferecer a qualidade de servio a determinada aplicao.
4. Concluso Geral

Neste artigo foram apresentados o ambiente de desenvolvimento utilizado e a

implementao de testes das VPNs para a avaliao de seu desempenho. O software
utilizado na montagem e verificao dos resultados totalmente gratuito (Iperf). O teste
qualidade de servio avaliou quatro cenrios para verificar se o CE prioriza os pacotes
em situao de congestionamento do acesso, de acordo com a classificao dos pacotes.
Os resultados mostraram que os mecanismos de QoS analisados apresentam bom
desempenho para os quatros cenrios. Alguns cuidados devem ser levados em
considerao quando na transmisso da classe tempo real (EF) com relao ao tamanho
de pacotes de dados na rede. Para evitar que o artigo ficasse excessivamente longo,
procurou-se enfatizar basicamente os testes, considerando que os passos anteriores
como as configuraes das VPNs j estivessem realizadas.
Referncia
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]

S.Blake, et. Al., RFC 2475, Na Architecture for Differentiated

Services,December 1998
Vegesna, S. IP Quality of Service, Cisco Press 2001.
U.Black., MPLS and Label Switching Networks Prentice Hall Series 2001
I. Pepelnjak, J. Guichard, MPLS and VPN Architectures Volume I Cisco
Press 2002
I. Pepelnjak, J. Guichard, J. Apcar. MPLS and VPN Architectures Volume II
Cisco Press 2003
E. Osborne, A. Simba, Engenharia de Trfego com MPLS Cisco Press 2003
P. Tonsu, G. Wieser, MPLS-Based VPNs Prentice Hall series 2001
Y.Rekhter, E. Rosen, RFC 2574, BGP/MPLS VPNs,March 1999
S. Ramachandra, D. Tappan, BGP Extended Communities Attribute, [draftramachandra-bgp-ext-communities-09.txt], work in progress, June 2001.
E. Rosen, R Callon, A. Viswanathan, RFC 3031, Multiprotocol Label Switching
Architecture,
January 2001. B. Jamoussi, L. Andersson, R. Callon and R. Dantu: ConstraintBased LSP Setup using LDP, RFC 3212, January 2002
Bilel Jamoussi, et al, Constraint-Based LSP Setup using LDP,[draft-ietf-mplscrldp-05.txt], January 2001
R. Braden, et al., RFC 2205, Resource ReServation Protocol (RSVP) Version
1, Functional Specification, September 1997.
S. Blake, D. Black, M. Carlson, E.Davies: An Architecture for Differentiated
Services, RFC 2475, December 1998.