WirelessBR

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: 

• O tráfego VoIP é entregue em formato TCP/IP, pelos PABX, media gateways, IP phones, softphones e VoIP phone adapters (será que esqueci alguém?), em um certo número de sites servidos pela rede, onde existem roteadores para transportar o tráfego não-local a cada site. 

• Os sites estão interligados por uma malha de links WAN (wide-area network) – tipicamente links seriais – e roteadores, em uma topologia não totalmente ligada.

• A rede TCP/IP oferece serviços de QoS no modelo DiffServ[1]. 

• Qual deve ser a banda reservada para o PHB EF (associado ao tráfego VoIP) nas interfaces dos links WAN dos roteadores? 

• Qual o delay médio (transmissão e enfileiramento) do tráfego VoIP na malha WAN?

• Qual a probabilidade do delay do tráfego VoIP na malha WAN exceder os limites desejáveis? 

• Os roteadores tem capacidade de processamento suficiente para acomodar o tráfego VoIP sem entrarem em sobrecarga[2]? 

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. 

 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. 
 

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. 
 

[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.