[GTER] Traffic Engineering

[Claus Rugani Topke]

Olá Carlos !

Quem é o autor deste artigo ?
De onde você tirou este texto ? Web ?....

[],
Claus

At 00:04 3/5/2002 -0300, you wrote:
>A todos, um artigo para discussão, críticas e sugestões.
>----
>
>Traffic Engineering
>
>
>Uma das 'buzzwords' associadas com MPLS é o famoso 'traffic engineering'. Mas
>afinal o que é isso? Se você chegou atrasado na festa e ainda não sabe se é
>para comer ou passar no cabelo, fique tranquilo: você certamente não está
>sozinho.
>
>Vamos a uma definição simplista, suficiente para nossos fins: 'Traffic
>Engineering' é um conjunto de métodos e práticas, com o objetivo de otimizar
>o fluxo de tráfego dentro de uma rede. Os principais parâmetros para avaliar
>esta otimização são o balanceamento de tráfego entre múltiplas rotas
>alternativas; a disponibilidade de rotas alternativas corretamente
>dimensionadas, caso haja necessidade de reroteamento; e a obtenção de um
>comportamento mais previsível (de preferência, determinístico) no processo de
>encaminhamento dos pacotes dentro da rede.
>
>A prática de Traffic Engineering é muito utilizada em grandes redes - aqueles
>backbones maravilhosos que se vê nos slides da Nanog. Porém, mesmo para estes
>grandes backbones, uma das reclamações recorrentes é a falta de uma base
>teórica para sustentar a atividade. Neste ponto, o pessoal do CAIDA e da
>própria NANOG vem fazendo um grande trabalho, mas que ainda é incipiente do
>ponto de vista educativo.
>
>Um ponto crucial para o Traffic Engineering é o conceito de 'source routing',
>que permite a seleção de rotas no ponto de ingresso da rede. Para comparar,
>em uma rede IP convencional o roteamento é feito nó por nó ('per-hop'). O uso
>do 'source routing' permite um maior controle sobre o processo de
>encaminhamento dos pacotes dentro da rede, que por sua vez viabiliza a
>atividade de engenharia de tráfego mesmo em uma rede grande. Para que isso
>seja aplicado, porém, é importante em primeiro lugar conhecer profundamente o
>seu tráfego. Isso implica na necessidade não só de medir o tráfego, mas
>também de investigar adequadamente o tráfego, para que possamos determinar o
>que é que deve ser medido.
>
>Vejamos agora o cenário brasileiro. Alguns fatores colaboram para que a
>atividade de engenharia de tráfego seja relegada a um segundo plano por aqui,
>como por exemplo:
>
>- A concentração de um grande volume de tráfego em uma única região (SP);
>- A banda ainda relativamente modesta que trafega no backbone nacional (mesmo
>com todo crescimento, ainda estamos bem aquém dos nossos amigos do hemisfério
>norte).
>- A quase absoluta ausência de SLAs para redes IP (digo SLAs *implementados*,
>não SLAs *assinados*. Esses tem de sobra).
>- A pouca penetração dos acordos de peering direto ou multilateral (via PTTs).
>- A falta de uma cultura adequada de medição do tráfego; não estamos falando
>de MRTG, mas de análise fina de tráfego por 'flow'.
>
>Apesar de historicamente estes fatores serem verdadeiros, vemos que vários
>deles estão mudando rapidamente. Com o aumento do tráfego, temos hoje no
>Brasil cada vez mais backbones de porte respeitável. Nossos problemas
>rapidamente se aproximam daqueles vividos nos EUA há um ou dois anos atrás,
>para não dizer agora.
>
>Em meio a este cenário, continuamos gerenciando tráfego mais ou menos da
>mesma forma que fazíamos antes. Basicamente, nossa interferência sobre o
>tráfego ainda se restringe de forma geral ao ajuste manual de parâmetros do
>BGP4, feita em geral de forma empírica. Não há que se discutir aqui a
>competência individual, ou o valor da experiência do pessoal que mantém os
>roteadores rodando. No entanto, estes processos humanos tem seus limites de
>escalabilidade, e isso certamente será cada vez mais problemático.
>
>Consideramos que é necessário que a discussão aberta sobre os mecanismos de
>'traffic engineering' seja fomentada, dentro da perspectiva de que se trata
>de uma atividade essencial à saúde do sistema como um todo. A discussão de
>políticas técnicas e administrativas deve ser encorajada, dentro de um
>espírito de colaboração aberto. Esperamos que o tema venha a merecer daqui
>por diante o carinho e a atenção que tanto merece.
>
>
>Carlos Ribeiro
>CTBC Telecom
>--
>GTER list    http://eng.registro.br/mailman/listinfo/gter