WirelessBR

WirelessBr é um site brasileiro, independente, sem vínculos com empresas ou organizações, sem finalidade  comercial,  feito por voluntários, para divulgação de tecnologia em telecomunicações 

Série de artigos sobre VoIP (4)
VoIP

Dimensionamento VoIP (WAN)   - Parte 01

José de Ribamar Smolka Ramos   (*)


Série
de artigos sobre VoIP
Quarto artigo - Parte 01

Série VoIP (4) – Dimensionamento VoIP (WAN)

J. R. Smolka 

Introdução

Este é o quarto artigo da nossa série, e, até aqui, o que me deu mais trabalho para conseguir um formato equilibrado entre teoria e prática. Vamos caracterizar o problema que queremos resolver: 

Normalmente o lado LAN (local area network) dos roteadores, onde é feita a transmissão inicial e a recepção final dos pacotes VoIP, não é um problema sério para dimensionamento (exceto WLAN – wireless LAN – que tem suas peculiaridades), porque quase sempre a situação ali é de bandwidth overkill. Então não vou me alongar neste aspecto. 

Neste artigo estaremos olhando o tráfego de voz de conexões VoIP já estabelecidas. O assunto sinalização (que é muito importante) será objeto de outro artigo. 

Agora que definimos nosso escopo de trabalho, como atacá-lo? Depois de várias tentativas descartadas, optei pelo seguinte formato: vamos criar um problema-exemplo e, enquanto vemos um método de solução, vamos intercalando aspectos relevantes da teoria que sustenta o método. 

A teoria do tráfego telefônico envolve um bocado de matemática (estatística e teoria das filas), mas vamos tentar manter as coisas práticas. Para aqueles que quiserem maior profundidade na discussão matemática, existem diversas referências na Internet[3]

Ao longo de todo este artigo meu headiness index[4] meter estará desligado, porque ele é um instrumento muito sensível, e corre o risco de quebrar ficando tanto tempo em VDO no extremo negativo da escala. Antes de começar, vou fazer algumas declarações de princípios. 

A maior parte dos problemas com VoIP não é causada pelas aplicações VoIP em si, mas pela necessidade de garantir a interoperação entre usuários VoIP e usuários POTS (plain old telephone service) convencionais. Existe uma citação (anônima, e sem a intenção de ofensa a nenhuma denominação religiosa) que diz: “Deus só conseguiu fazer o mundo em sete dias porque Ele não tinha que se preocupar com legacy systems”. 

VoIP tem sido um assunto “quente” no nível corporativo, nas operadoras e nos fornecedores de equipamentos (datacom e telecom), mas, em minha opinião, pelos motivos errados (embora importantes). O foco principal tem sido, pelo lado das corporações e das operadoras, na redução de custos operacionais[5]

Redução de custos operacionais com serviços de voz pelas corporações significa queda de receita nas operadoras, e, se isto não bastasse, a queda de receita vai se acentuando ainda mais, à medida que a tecnologia VoIP penetra na base de clientes residenciais, via disponibilidade cada vez maior de acessos de banda larga à Internet. 

Os fornecedores de equipamentos datacom, cuja base de clientes tradicional está no mercado corporativo, e onde eles já estão faturando com a venda de soluções corporate VoIP, enxergam o mercado carrier-class VoIP como uma oportunidade para agregar clientes high profile à sua carteira. 

Os fornecedores de equipamentos telecom tradicionais, que já tinham o seu interesse por VoIP despertado pelas demandas das operadoras preocupadas com a queda das receitas de voz, ficam ainda mais preocupados, porque eles não querem ver a sua base de clientes tradicionais (e, conseqüentemente, seu faturamento) ser erodida por estes novos entrantes. 

Enfim, estão todos interessados em VoIP por razões financeiras, e, no caso das operadoras e dos fornecedores de equipamentos telecom, pelo desejo de preservar os seus modelos de negócio. Quase ninguém está propondo VoIP como base para novos serviços e modelos de negócio. 

A conseqüência é que não há muito esforço em modelar as aplicações VoIP de forma inovadora. Queremos apenas incorporar, o mais rápido possível, VoIP no nosso portfolio de negócios. E, com isso, cresce a pressão para que a rede TCP/IP forneça um meio de transporte o mais parecido possível com a rede telefônica convencional. Minha opinião é que isto tudo beira o insano. 

Conforme já disse antes, não acredito que este seja o melhor caminho. Mas, como dizia o saudoso Adoniran Barbosa naquele comercial de cerveja: “nóis viemo aqui pra bebê ou prá conversá?” 

Um exemplo do problema: 

Vamos usar como exemplo, ao longo de todo este artigo, uma rede TCP/IP com a topologia mostrada na figura 1. 

Figura 1 – Topologia exemplo

Temos quatro sites (numerados de 1 a 4), cada um deles com um roteador (também numerados de 1 a 4). Os roteadores estão interconectados por quatro links WAN, identificados pelos pares dos números dos roteadores conectados (1-2 ou 2-1, 2-3 ou 3‑2, 3-4 ou 4-3 e 1-4 ou 4-1). 

Numa topologia genérica, podemos ter n roteadores, não necessariamente todos em sites onde ocorre a transmissão inicial e a recepção final do tráfego VoIP, e não necessariamente cada par de roteadores possui um link direto de conexão entre eles. 

Antes de mais nada, precisamos conhecer duas coisas: quais são as características relevantes de cada link da topologia (banda total, tipo de encapsulamento da interface, e uso ou não de MPLS e cRTP[6] no link); e quais são as rotas para encaminhamento de tráfego entre os sites (de acordo com as decisões tomadas pelos protocolos de dynamic routing utilizados). Vamos organizar estes dados em arrays, o que facilita a implementação posterior do método na forma de um programa de computador. 

A figura 2 mostra o array (bidimensional) de características dos links para nossa topologia exemplo. O elemento do array com índices i e j descreve as características do link entre os roteadores i e j (se existir). Os elementos na diagonal principal sempre tem indicação de não existência (porque não existem links de um roteador para ele mesmo), e elementos simétricos em relação à diagonal principal são sempre idênticos (porque representam o mesmo link). É conveniente, por enquanto, tratar os links como se fossem entidades unidirecionais (i.e.: link i-j diferente do link j-i). Isto vai ficar mais claro ao longo do desenvolvimento do exemplo. 

 

 

Roteador j

1

2

3

4

Roteador i

1

0; 0; 0; 0

2; 1920; 0; 1

0; 0; 0; 0

2; 1920; 0; 1

2

2; 1920; 0; 1

0; 0; 0; 0

2; 1920; 0; 1

0; 0; 0; 0

3

0; 0; 0; 0

2; 1920; 0; 1

0; 0; 0; 0

2; 1920; 0; 1

4

2; 1920; 0; 1

0; 0; 0; 0

2; 1920; 0; 1

0; 0; 0; 0

 Figura 2 – Array de características dos links

Cada elemento do array é uma estrutura de dados, com os seguintes componentes: 

Tipo do link     Número inteiro, codifica a existência ou não do link e, caso exista, qual o tipo de encapsulamento é utilizado na interface. Valores válidos no nosso exemplo são: 

0    Indica link inexistente (neste caso, todos os outros elementos serão iguais a zero); 

1    Indica link Ethernet[7] (IEEE 802.3); 

2    Indica link serial com encapsulamento PPP; 

3    Indica link serial com encapsulamento frame-relay

Banda total     Número real, indica a banda total do link, em Kbps. 

MPLS              Número inteiro, codifica o uso ou não de MPLS no link. Valores válidos no nosso exemplo são: 

0    Indica não utilização de MPLS no link

1    Indica utilização de MPLS no link

cRTP               Número inteiro, codifica o uso ou não de cRTP no link. Valores válidos no nosso exemplo são: 

0    Indica não utilização de cRTP no link

1    Indica utilização de cRTP no link

No nosso exemplo, todos os quatro links são E1[8] (os valores da banda total no exemplo correspondem à banda líquida, porque os canais de sincronismo e sinalização não são usados para tráfego), utilizam encapsulamento PPP sobre interfaces seriais sem MPLS e com cRTP. 

O array de rotas é mostrado na figura 3. Como a rota que vai do roteador i até o roteador j pode ter vários hops intermediários (máximo n–1), este é um array tridimensional. Os índices i e j identificam, respectivamente, os roteadores de início e fim da rota, e o índice k identifica os hops na rota. 
 

Roteadores

Hops (k)

i

j

1

2

3

1

1

0

0

0

1

2

2

0

0

1

3

2

3

0

1

4

4

0

0

2

1

1

0

0

2

2

0

0

0

2

3

3

0

0

2

4

3

4

0

3

1

4

1

0

3

2

2

0

0

3

3

0

0

0

3

4

4

0

0

4

1

1

0

0

4

2

1

2

0

4

3

3

0

0

4

4

0

0

0

Figura 3 - Array de rotas

Cada elemento do array é o número do roteador que é um hop na rota de i para j. Para facilitar a implementação posterior, quando o elemento (i,j,1) for igual a zero, isto indica que não há rota entre i e j (em geral isto só acontecerá quando i=j), e quando o elemento (i,j,k) contiver um valor igual a j, isto significa fim da rota. As posições não utilizadas na dimensão k são iguais a zero. 

É importante que este array seja coerente com as rotas negociadas via protocolos de dynamic routing. Para uma implementação realmente sofisticada deste método, inclua rotinas para simular o comportamento dos protocolos de dynamic routing utilizados. 

Agora precisamos conhecer as características do tráfego VoIP (Kbps e pps) que será cursado entre os sites. Mas, especialmente no caso das operadoras de telefonia, é comum que a intensidade do tráfego telefônico seja expressa em Erlangs. E os pacotes de voz que serão gerados a partir daquela intensidade de tráfego tem algumas características importantes para a nossa análise. 

Portanto, antes de continuarmos o nosso exemplo de dimensionamento, temos que fazer dois parênteses (meio grandes), para discutir o essencial da teoria do tráfego telefônico e as peculiaridades dos pacotes de voz. 
 


[1] Ver o terceiro artigo desta série.
 
[2] Cada pacote tem de ser processado pelo roteador, portanto o principal fator de sobrecarga não é o volume do tráfego, mas o número de pacotes por segundo (pps) a processar. E, como veremos, o tráfego VoIP gera muitos pps.
 
[3] Recomendo: Teletraffic Engineering Handbook em www.tele.dtu.dk/teletraffic/handbook/telehook.pdf e o seu complemento de revisão de estatística em www.tele.dtu.dk/teletraffic/mathematics/mathematics.pdf.
 
[4] Descrição do que é o headiness index no final do primeiro artigo desta série.
 
[5] No jargão das operadoras, o custo operacional é geralmente chamado de OPEX (operational expenditures).
 
[6] Links cRTP (compressed RTP) fazem compressão dos headers de transporte e IP na transmissão e descompressão na recepção, possivelmente usando ASICs (application-specific integrated circuits). O cRTP está descrito na RFC 2508 (versão simples) e na RFC 3545 (enhanced cRTP – para links com alto delay e taxa de perda grande)
 
[7] WAN Ethernet? Sim. Estão cada vez mais populares links Gigabit Ethernet (1 Gbps) e Metro Ethernet (10 Gbps) sobre fibras óticas monomodo. Para links metropolitanos, é ótimo.
 
[8] Um link E1 (recomendação G.703 da ITU-T) é composto de 32 canais TDM (time-division multiplexing) de 64 Kbps cada. 30 canais de tráfego, um canal de sinalização e um canal de sincronismo.

[Próxima]


José de Ribamar Smolka Ramos (smolka@terra.com.br) é engenheiro eletricista (UFBa 1982), com especialização em gestão da qualidade (CETEAD/UFBa 1994) e MBA executivo (FGV RJ/Grupo Telefonica 2001). 
Trabalha na área de Informática desde 1980, tendo atuado em empresas das áreas financeira, industrial e serviços, estando desde 1989 na área de telecomunicações. Desde 1995 dedica-se ao projeto, implantação e gestão operacional de infra-estruturas corporativas de comunicação de dados e serviços baseadas na arquitetura TCP/IP, envolvendo infra-estrutura LAN e WAN, acesso remoto e interconexão de redes.
Principais áreas de interesse técnico: segurança da informação, engenharia de tráfego e garantia de QoS na arquitetura TCP/IP e gerência de redes.
Atualmente é especialista técnico da Telebahia Celular S/A (Vivo), e (desde 1993) é professor do curso de bacharelado em Informática da Universidade Católica do Salvador, nas cadeiras de Linguagens para Aplicações Comerciais e Introdução aos Sistemas de Computação.
Uma coleção de suas "mensagens-artigos" em grupos de debates está disponível em: http://www.wirelessbrasil.org/jose_smolka/js01.html.

Home WirelessBR                     Próxima