[GTER] Traffic Engineering
Loureiro, Rodrigo
RLoureiro at unispherenetworks.com
Mon May 6 11:28:00 -03 2002
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.
More information about the gter
mailing list