<!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 6.00.2715.400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Loureiro, Rodrigo
[mailto:RLoureiro@unispherenetworks.com]<BR><B>Sent:</B> Monday, May 06, 2002
8:08 AM<BR><B>To:</B> 'gter@eng.registro.br'<BR><B>Subject:</B> RE: [GTER]
Traffic Engineering<BR><BR></FONT></DIV>
<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><FONT color=#0000ff><FONT
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.<SPAN
class=008171615-06052002> </SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial><FONT color=#0000ff><FONT
size=2><SPAN
class=008171615-06052002></SPAN></FONT></FONT></FONT></SPAN> </DIV>
<DIV><SPAN class=889105614-06052002><FONT face=Arial><FONT><FONT color=#ff0000
size=2><SPAN class=008171615-06052002><RP> Pelo jeito vc nao viu minha
palestra.</SPAN></FONT></FONT></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
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></BLOCKQUOTE><BR>
<P><FONT face=Arial size=2>======================================= </FONT></P>
<P><FONT face=Arial size=2>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></BLOCKQUOTE></BODY></HTML>