[GTER] Traffic Engineering

[Rubens Kuhl Jr.]

Algo a ser levado em conta é que muito do que é implementado com
IP-Traffic-Engineering em backbones americanos, é feito aqui com Engenharia
em L2 (ATM) para reroteamento em nível de backbone. Isso já pode garantir
SLAs reais quando requisitados... a grande demanda por IP-TE surgiu com a
migração de ATM para POS; quando os backbones brasileiros não quiserem ou
puderem mais pagar o cell-tax, veremos a mesma migração para POS e a mesma
demanda por IP-TE para que o L3 implemente os recursos antes disponiblizados
pelo L2. Por enquanto, a sobre-capacidade já instalada e a diminuição de
capex apontam para uma manutenção do status-quo do ATM no core, com o POS
surgindo no nível de acesso onde o cliente não quer pagar o cell-tax.

Ter ou não acordos de peering entre os diversos AS só começará a demandar
IP-TE quando se tornar comum mais de um ponto de interconexão (vide
apresentação do RSix na última GT-ER); talvez alguém da RNP e EBT (que faz
peering em SP, RJ e DF) possam dizer se já sentiram essa necessidade.


Rubens Kühl Jr.

----- Original Message -----
From: "Carlos Ribeiro" <carribeiro at yahoo.com>
To: <gter at eng.registro.br>
Sent: Friday, May 03, 2002 12:04 AM
Subject: [GTER] Traffic Engineering


> 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