[GTER] Traffic Engineering

[Loureiro, Rodrigo]

Carlos,

Apenas para expandir o escopo de aplicação, traffic engineering já é
utilizado para garantir parâmetros de qualidade de serviço dentro de
backbones IP para aplicações críticas. Por exemplo, imagine uma chamada de
voz originada na rede TDM, passando pelo backbone intercity via
infra-estrutura IP, e sendo terminada na rede TDM novamente. Nesse caso,
poder-se-á utilizar traffic engineering para sinalizar um "CAC" dentro do
backbone IP, a fim de garantir recursos fim-a-fim para essa chamada de voz.
Enfim, já existe tecnologia capaz de fazer grande uso dos conceitos de
traffic engineering.


Abraços,
--

Rodrigo Loureiro

-----Original Message-----
From: Carlos Ribeiro [mailto:carribeiro at yahoo.com]
Sent: Thursday, May 02, 2002 8:04 PM
To: gter at eng.registro.br
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

======================================= 
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.