[GTER] Traffic Engineering

[Reinaldo Penno]

>-----Original Message-----
>From: Loureiro, Rodrigo [mailto:RLoureiro at unispherenetworks.com]
>Sent: Monday, May 06, 2002 7:27 AM
>To: 'gter at eng.registro.br'
>Subject: RE: [GTER] Traffic Engineering
>
>
>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... 

papo de vendedor...vamos ver se no proximo email vc da argumentos mais
convincentes. 

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.
>--
>GTER list    http://eng.registro.br/mailman/listinfo/gter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://eng.registro.br/pipermail/gter/attachments/20020506/d9740d0f/attachment.html>