<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [GTER] Traffic Engineering</TITLE>
<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2>Reinaldo,</FONT></SPAN></DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2>Acredito realmente que o primeiro passo em direção a uma rede convergente
seja ter uma infra-estrutura capaz de acomodar o pior caso, seja esse voz,
vídeo etc. </FONT></SPAN></DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2>Lembro-me da sua palestra sobre traffic engineering, onde você sugeria
atualizar os drivers TCP dos hosts da rede , a fim de otiimzar o consumo de
banda. Não preciso dizer que não concordo com esse ponto-de-vista, e que
ele é completamente inviável para um provedor de serviço, no entanto
respeito-o.</FONT></SPAN></DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2>Carlos, da próxima vez responderei em offline.</FONT></SPAN><SPAN
class=889105614-06052002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN></DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2>--</FONT></SPAN></DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial color=#0000ff
size=2>Rodrigo</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Reinaldo Penno
[mailto:reinaldo_penno@nortelnetworks.com]<BR><B>Sent:</B> Monday, May 06,
2002 7:37 AM<BR><B>To:</B> gter@eng.registro.br<BR><B>Subject:</B> RE: [GTER]
Traffic Engineering<BR><BR></FONT></DIV><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 target=_blank
href="http://eng.registro.br/mailman/listinfo/gter">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 target=_blank
href="http://eng.registro.br/mailman/listinfo/gter">http://eng.registro.br/mailman/listinfo/gter</A></FONT>
<BR><FONT size=2>></FONT> </P></BLOCKQUOTE></BODY></HTML>
<BR>
<P><FONT SIZE=2 FACE="Arial">======================================= </FONT></P>
<P><FONT SIZE=2 FACE="Arial">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.</FONT></P>