[GTER] Traffic Engineering

[Loureiro, Rodrigo]

Carlos,

Acho que o problema começa antes disso. Primeiramente você precisa ter uma
infra-estrutura IP capaz de atender as condições de contorno de sua
aplicação (ex: baixa latência). Existem diversos pré-requisitos
arquiteturais para se conseguir isso, como arquitetura distribuída baseada
em hardware (ASICs, FPGAs), implementação de filas em hardware por usuário,
wire-speed, capacidade de coletar estatísitcas granulares em wire-speed sem
afetar a performance do equipamento... Imagine que exista uma política de
QoS implementada no backbone, de forma a dar preferência a aplicações
críticas. E,num determinado instante de tempo, experimentou-se congestão num
nó da rede. Se esse nó da rede não conseguir diferenciar tráfego tão rápido
quanto a velocidade da linha, certamente os pacotes da aplicação crítica
serão discartados, mesmo que a quantidade de tráfego crítico seja menor do
que a banda disponível no tronco congestionado.

Enfim, concordo que convergir diferentes tecnologias numa mesma
infra-estrutura seja complicado num primeiro momento, principalmente no
tocante à capacity-planning, engenharia de tráfego... Entretanto, existe
solução estável para todos os pontos levantados abaixo e, uma vez feito da
forma correta e endereçando todos as condições de contorno relevantes, a
operação fica bastante otimizada.


--
Rodrigo



-----Original Message-----
From: Carlos Ribeiro [mailto:carribeiro at yahoo.com]
Sent: Friday, May 03, 2002 2:38 PM
To: gter at eng.registro.br
Subject: Re: [GTER] Traffic Engineering


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
--
GTER list    http://eng.registro.br/mailman/listinfo/gter

======================================= 
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.