<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>RE: [GTER] Traffic Engineering</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<P><FONT SIZE=2>>-----Original Message-----</FONT>
<BR><FONT SIZE=2>>From: Loureiro, Rodrigo [<A HREF="mailto:RLoureiro@unispherenetworks.com">mailto:RLoureiro@unispherenetworks.com</A>]</FONT>
<BR><FONT SIZE=2>>Sent: Monday, May 06, 2002 7:27 AM</FONT>
<BR><FONT SIZE=2>>To: 'gter@eng.registro.br'</FONT>
<BR><FONT SIZE=2>>Subject: RE: [GTER] Traffic Engineering</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Carlos,</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Acho que o problema começa antes disso. Primeiramente você </FONT>
<BR><FONT SIZE=2>>precisa ter uma</FONT>
<BR><FONT SIZE=2>>infra-estrutura IP capaz de atender as condições de contorno de sua</FONT>
<BR><FONT SIZE=2>>aplicação (ex: baixa latência). Existem diversos pré-requisitos</FONT>
<BR><FONT SIZE=2>>arquiteturais para se conseguir isso, como arquitetura </FONT>
<BR><FONT SIZE=2>>distribuída baseada</FONT>
<BR><FONT SIZE=2>>em hardware (ASICs, FPGAs), implementação de filas em hardware </FONT>
<BR><FONT SIZE=2>>por usuário,</FONT>
<BR><FONT SIZE=2>>wire-speed, capacidade de coletar estatísitcas granulares em </FONT>
<BR><FONT SIZE=2>>wire-speed sem</FONT>
<BR><FONT SIZE=2>>afetar a performance do equipamento... </FONT>
</P>
<P><FONT SIZE=2>papo de vendedor...vamos ver se no proximo email vc da argumentos mais convincentes. </FONT>
</P>
<P><FONT SIZE=2>Imagine que exista uma </FONT>
<BR><FONT SIZE=2>>política de</FONT>
<BR><FONT SIZE=2>>QoS implementada no backbone, de forma a dar preferência a aplicações</FONT>
<BR><FONT SIZE=2>>críticas. E,num determinado instante de tempo, experimentou-se </FONT>
<BR><FONT SIZE=2>>congestão num</FONT>
<BR><FONT SIZE=2>>nó da rede. Se esse nó da rede não conseguir diferenciar </FONT>
<BR><FONT SIZE=2>>tráfego tão rápido</FONT>
<BR><FONT SIZE=2>>quanto a velocidade da linha, certamente os pacotes da </FONT>
<BR><FONT SIZE=2>>aplicação crítica</FONT>
<BR><FONT SIZE=2>>serão discartados, mesmo que a quantidade de tráfego crítico </FONT>
<BR><FONT SIZE=2>>seja menor do</FONT>
<BR><FONT SIZE=2>>que a banda disponível no tronco congestionado.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Enfim, concordo que convergir diferentes tecnologias numa mesma</FONT>
<BR><FONT SIZE=2>>infra-estrutura seja complicado num primeiro momento, principalmente no</FONT>
<BR><FONT SIZE=2>>tocante à capacity-planning, engenharia de tráfego... </FONT>
<BR><FONT SIZE=2>>Entretanto, existe</FONT>
<BR><FONT SIZE=2>>solução estável para todos os pontos levantados abaixo e, uma </FONT>
<BR><FONT SIZE=2>>vez feito da</FONT>
<BR><FONT SIZE=2>>forma correta e endereçando todos as condições de contorno </FONT>
<BR><FONT SIZE=2>>relevantes, a</FONT>
<BR><FONT SIZE=2>>operação fica bastante otimizada.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>--</FONT>
<BR><FONT SIZE=2>>Rodrigo</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>-----Original Message-----</FONT>
<BR><FONT SIZE=2>>From: Carlos Ribeiro [<A HREF="mailto:carribeiro@yahoo.com">mailto:carribeiro@yahoo.com</A>]</FONT>
<BR><FONT SIZE=2>>Sent: Friday, May 03, 2002 2:38 PM</FONT>
<BR><FONT SIZE=2>>To: gter@eng.registro.br</FONT>
<BR><FONT SIZE=2>>Subject: Re: [GTER] Traffic Engineering</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>On Fri 03 May 2002 15:55, you wrote:</FONT>
<BR><FONT SIZE=2>>> Enfim, já existe tecnologia capaz de fazer grande uso dos </FONT>
<BR><FONT SIZE=2>>conceitos de</FONT>
<BR><FONT SIZE=2>>> traffic engineering.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Rodrigo,</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Certamente que a tecnologia existe... RSVP-TE, CR-LDP e toda </FONT>
<BR><FONT SIZE=2>>uma sopa de </FONT>
<BR><FONT SIZE=2>>letrinhas para estabelecer túneis 'automagicamente' dentro uma </FONT>
<BR><FONT SIZE=2>>rede MPLS. No</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>entanto, não foi esse o ponto que eu estava levantando.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Para tirar proveito dessas ferramentas, é necessário que seja feito um </FONT>
<BR><FONT SIZE=2>>trabalho sério de dimensionamento e de engenharia de tráfego. </FONT>
<BR><FONT SIZE=2>>Por exemplo:</FONT>
<BR><FONT SIZE=2>>em </FONT>
<BR><FONT SIZE=2>>uma rede de voz tradicional, existe o modelo de Erlang, onde </FONT>
<BR><FONT SIZE=2>>todo interesse </FONT>
<BR><FONT SIZE=2>>de tráfego é considerado. O resultado final indica o </FONT>
<BR><FONT SIZE=2>>dimensionamento correto</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>dos troncos entre as centrais para carregar o tráfego especificado.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Agora, vamos fazer tudo sobre IP, com MPLS e RSVP-TE. Qual </FONT>
<BR><FONT SIZE=2>>será a banda </FONT>
<BR><FONT SIZE=2>>necessária em cada tronco? Se a única aplicação na rede for </FONT>
<BR><FONT SIZE=2>>voz-sobre-IP, </FONT>
<BR><FONT SIZE=2>>então o modelo de Erlang se aplica, pelo menos no sentido de </FONT>
<BR><FONT SIZE=2>>prever quantas </FONT>
<BR><FONT SIZE=2>>conversações simultâneas precisam ser suportadas no mesmo </FONT>
<BR><FONT SIZE=2>>link. Em princípio</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>(há controvérsias a respeito disso), bastaria converter o </FONT>
<BR><FONT SIZE=2>>número de canais</FONT>
<BR><FONT SIZE=2>>em </FONT>
<BR><FONT SIZE=2>>volume de banda, usando para isso os parâmetros de </FONT>
<BR><FONT SIZE=2>>dimensionamento do canal </FONT>
<BR><FONT SIZE=2>>emulado com voz sobre IP (incluindo overhead, etc.).</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Agora, vejamos as diferenças de se fazer isso sobre uma rede IP/MPLS. </FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>1) Suponhamos que um determinado roteador 'caia'. O tráfego de </FONT>
<BR><FONT SIZE=2>>voz deve ser </FONT>
<BR><FONT SIZE=2>>reroteado por outro caminho. No caso da central de voz, </FONT>
<BR><FONT SIZE=2>>existem conceitos </FONT>
<BR><FONT SIZE=2>>como rota alternativa e rota de transbordo, que permitem ao </FONT>
<BR><FONT SIZE=2>>engenheiro de </FONT>
<BR><FONT SIZE=2>>tráfego especificar, de antemão, qual será a política de </FONT>
<BR><FONT SIZE=2>>roteamento em caso </FONT>
<BR><FONT SIZE=2>>de problemas. Estas rotas (alternativa e transbordo) também </FONT>
<BR><FONT SIZE=2>>seguem políticas</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>bem definidas, e são dimensionadas de acordo com os estudos de </FONT>
<BR><FONT SIZE=2>>engenharia de</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>tráfego. Assim, a operadora sabe que, se uma rota 'cai', a </FONT>
<BR><FONT SIZE=2>>rota de reserva </FONT>
<BR><FONT SIZE=2>>tem capacidade para suportar o tráfego adicional.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>No caso da rede IP/MPLS, a escolha da rota alternativa depende </FONT>
<BR><FONT SIZE=2>>em grande </FONT>
<BR><FONT SIZE=2>>medida do IGP utilizado (OSPF-TE ou MP-BGP, por exemplo), e </FONT>
<BR><FONT SIZE=2>>dos pesos usados</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>para cada uma das rotas. No entanto, qualquer um que já tenha tentado </FONT>
<BR><FONT SIZE=2>>configurar sistemas de roteamento IP dinâmico sabe o quanto é </FONT>
<BR><FONT SIZE=2>>difícil prever</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>exatamente o que vai ocorrer em cada cenário; mais difícil </FONT>
<BR><FONT SIZE=2>>ainda é acertar</FONT>
<BR><FONT SIZE=2>>os </FONT>
<BR><FONT SIZE=2>>pesos de tal forma que você consiga prever o que acontece em </FONT>
<BR><FONT SIZE=2>>*qualquer* </FONT>
<BR><FONT SIZE=2>>cenário. Uma pequena mexida em um ajuste local, e a </FONT>
<BR><FONT SIZE=2>>convergência da rede</FONT>
<BR><FONT SIZE=2>>para </FONT>
<BR><FONT SIZE=2>>outros casos também é afetada. Assim, é fácil que uma decisão de</FONT>
<BR><FONT SIZE=2>>reroteamento </FONT>
<BR><FONT SIZE=2>>faça com que o tráfego, que antes cabia no tronco principal, </FONT>
<BR><FONT SIZE=2>>sature o tronco</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>reserva. </FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>2) Por enquanto, era só voz... agora, coloque no mesmo tronco </FONT>
<BR><FONT SIZE=2>>voz, dados, </FONT>
<BR><FONT SIZE=2>>etc. Neste momento, ainda não há modelos adequados para prever </FONT>
<BR><FONT SIZE=2>>o que é que </FONT>
<BR><FONT SIZE=2>>pode acontecer quando houver uma falha. O resultado vai </FONT>
<BR><FONT SIZE=2>>depender do bom </FONT>
<BR><FONT SIZE=2>>senso, da experiência (e sorte) do engenheiro responsável pelo </FONT>
<BR><FONT SIZE=2>>roteamento</FONT>
<BR><FONT SIZE=2>>IP.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Felizmente (ou infelizmente?) o problema ainda não é sério, </FONT>
<BR><FONT SIZE=2>>porque ainda é </FONT>
<BR><FONT SIZE=2>>mais barato superdimensionar os troncos de dados do que fazer um bom</FONT>
<BR><FONT SIZE=2>>trabalho </FONT>
<BR><FONT SIZE=2>>de engenharia de tráfego. No entanto, por mais que desejemos </FONT>
<BR><FONT SIZE=2>>que seja assim,</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>isso não deve permanecer para sempre... Mesmo hoje, com um </FONT>
<BR><FONT SIZE=2>>cenário econômico</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>recessivo, falar em superdimensionamento é tabu.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Em resumo: Traffic Engineering não se resolve só com uma </FONT>
<BR><FONT SIZE=2>>tecnologia, ou com </FONT>
<BR><FONT SIZE=2>>um protocolo, por melhores que sejam. É necessário desenvolver </FONT>
<BR><FONT SIZE=2>>modelos, </FONT>
<BR><FONT SIZE=2>>práticas, e principalmente, cultura para que isso seja </FONT>
<BR><FONT SIZE=2>>possível. A não ser,</FONT>
<BR><FONT SIZE=2>>é </FONT>
<BR><FONT SIZE=2>>claro, que continue sendo mais barato superdimensionar os troncos...</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Carlos Ribeiro</FONT>
<BR><FONT SIZE=2>>CTBC Telecom</FONT>
<BR><FONT SIZE=2>>--</FONT>
<BR><FONT SIZE=2>>GTER list <A HREF="http://eng.registro.br/mailman/listinfo/gter" TARGET="_blank">http://eng.registro.br/mailman/listinfo/gter</A></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>======================================= </FONT>
<BR><FONT SIZE=2>>This email message is for the sole use of the intended </FONT>
<BR><FONT SIZE=2>>recipient (s) and may</FONT>
<BR><FONT SIZE=2>>contain confidential and privileged information, including without</FONT>
<BR><FONT SIZE=2>>limitation, Confidential and/or Proprietary Information belonging to</FONT>
<BR><FONT SIZE=2>>Unisphere Networks, Inc. Any unauthorized review, use, disclosure or</FONT>
<BR><FONT SIZE=2>>distribution is prohibited. If you are not the intended </FONT>
<BR><FONT SIZE=2>>recipient, please</FONT>
<BR><FONT SIZE=2>>contact the sender by reply email and destroy all copies of </FONT>
<BR><FONT SIZE=2>>the original</FONT>
<BR><FONT SIZE=2>>message.</FONT>
<BR><FONT SIZE=2>>--</FONT>
<BR><FONT SIZE=2>>GTER list <A HREF="http://eng.registro.br/mailman/listinfo/gter" TARGET="_blank">http://eng.registro.br/mailman/listinfo/gter</A></FONT>
<BR><FONT SIZE=2>></FONT>
</P>
</BODY>
</HTML>