[GTER] Traffic Engineering

[Carlos Ribeiro]

On Fri 03 May 2002 15:55, you wrote:
> Enfim, já existe tecnologia capaz de fazer grande uso dos conceitos de
> traffic engineering.

Rodrigo,

Certamente que a tecnologia existe... RSVP-TE, CR-LDP e toda uma sopa de 
letrinhas para estabelecer túneis 'automagicamente' dentro uma rede MPLS. No 
entanto, não foi esse o ponto que eu estava levantando.

Para tirar proveito dessas ferramentas, é necessário que seja feito um 
trabalho sério de dimensionamento e de engenharia de tráfego. Por exemplo: em 
uma rede de voz tradicional, existe o modelo de Erlang, onde todo interesse 
de tráfego é considerado. O resultado final indica o dimensionamento correto 
dos troncos entre as centrais para carregar o tráfego especificado.

Agora, vamos fazer tudo sobre IP, com MPLS e RSVP-TE. Qual será a banda 
necessária em cada tronco? Se a única aplicação na rede for voz-sobre-IP, 
então o modelo de Erlang se aplica, pelo menos no sentido de prever quantas 
conversações simultâneas precisam ser suportadas no mesmo link. Em princípio 
(há controvérsias a respeito disso), bastaria converter o número de canais em 
volume de banda, usando para isso os parâmetros de dimensionamento do canal 
emulado com voz sobre IP (incluindo overhead, etc.).

Agora, vejamos as diferenças de se fazer isso sobre uma rede IP/MPLS. 

1) Suponhamos que um determinado roteador 'caia'. O tráfego de voz deve ser 
reroteado por outro caminho. No caso da central de voz, existem conceitos 
como rota alternativa e rota de transbordo, que permitem ao engenheiro de 
tráfego especificar, de antemão, qual será a política de roteamento em caso 
de problemas. Estas rotas (alternativa e transbordo) também seguem políticas 
bem definidas, e são dimensionadas de acordo com os estudos de engenharia de 
tráfego. Assim, a operadora sabe que, se uma rota 'cai', a rota de reserva 
tem capacidade para suportar o tráfego adicional.

No caso da rede IP/MPLS, a escolha da rota alternativa depende em grande 
medida do IGP utilizado (OSPF-TE ou MP-BGP, por exemplo), e dos pesos usados 
para cada uma das rotas. No entanto, qualquer um que já tenha tentado 
configurar sistemas de roteamento IP dinâmico sabe o quanto é difícil prever 
exatamente o que vai ocorrer em cada cenário; mais difícil ainda é acertar os 
pesos de tal forma que você consiga prever o que acontece em *qualquer* 
cenário. Uma pequena mexida em um ajuste local, e a convergência da rede para 
outros casos também é afetada. Assim, é fácil que uma decisão de reroteamento 
faça com que o tráfego, que antes cabia no tronco principal, sature o tronco 
reserva. 

2) Por enquanto, era só voz... agora, coloque no mesmo tronco voz, dados, 
etc. Neste momento, ainda não há modelos adequados para prever o que é que 
pode acontecer quando houver uma falha. O resultado vai depender do bom 
senso, da experiência (e sorte) do engenheiro responsável pelo roteamento IP.

Felizmente (ou infelizmente?) o problema ainda não é sério, porque ainda é 
mais barato superdimensionar os troncos de dados do que fazer um bom trabalho 
de engenharia de tráfego. No entanto, por mais que desejemos que seja assim, 
isso não deve permanecer para sempre... Mesmo hoje, com um cenário econômico 
recessivo, falar em superdimensionamento é tabu.


Em resumo: Traffic Engineering não se resolve só com uma tecnologia, ou com 
um protocolo, por melhores que sejam. É necessário desenvolver modelos, 
práticas, e principalmente, cultura para que isso seja possível. A não ser, é 
claro, que continue sendo mais barato superdimensionar os troncos...


Carlos Ribeiro
CTBC Telecom