[GTER] Construindo um modelo de Engenharia de Tráfego

[Carlos Ribeiro]

[tenho a impressão que essa mensagem não foi enviada corretamente para a 
lista... segue uma segunda cópia. peço desculpas caso chegue em duplicidade]

A todos,

Obrigado pelos comentários, e em especial ao Reinaldo pelas referências 
enviadas. De toda forma, continuo sentindo que ainda falta aprofundar a 
discussão. Temos aqui no grupo representantes da maioria dos backbones 
brasileiros, mas mesmo assim, a discussão ainda não 'esquentou'... Acho que à 
medida que formos colocando as idéias no ar, a discussão deve aumentar, para 
benefício de todos. Assim... vamos ao que interessa, certo?

----
Construindo um modelo de Engenharia de Tráfego 


Um dos principais desafios ao estudar o tema 'Engenharia de Tráfego' é a sua 
extensão e complexidade. Em geral, os modelos apresentados são bastante 
complexos, e partem do princípio de que o leitor já está plenamente 
familiarizado com os problemas típicos de uma rede IP de grande porte, com 
centenas de roteadores (!). Vamos partir de premissas diferentes: um modelo 
simplificado, que nos permitirá exercitar alguns dos conceitos básicos de 
Engenharia de Tráfego IP. À medida que o nosso backbone cresce, vamos ver 
como novas técnicas de medição e planejamento podem ser aplicadas.


1. Caso trivial: o backbone de um só roteador

Vamos imaginar uma operadora de serviços de conectividade IP que possua 
apenas um único roteador, com todos os seus clientes diretamente conectados. 
Para todos os efeitos, o roteador é do tipo ideal: possui capacidade de 
comutação ilimitada, sendo capaz de sustentar o tráfego em taxa máxima, em 
ambos os sentidos, sem perda de pacotes. A única restrição é a taxa das 
interfaces de acesso, com as quais os clientes se ligam à rede. Nosso 
objetivo é garantir a qualidade do acesso dos clientes, de tal forma que 
estes consigam usar a rede para se comunicar sem congestionamento.

Neste cenário ideal, o trabalho de planejamento se restringe ao 
dimensionamento dos acessos, garantindo que cada cliente tenha um 'tubo' com 
capacidade suficiente para o seu tráfego de pico. Este trabalho pode ser 
feito de forma bastante simples, monitorando o perfil de tráfego de cada um 
dos links para determinar a sua necessidade; o MRTG ou o RRDTool atendem 
perfeitamente a esta finalidade. Sempre que o tráfego usual de pico diário 
exceder um certo limite pré-estabelecido, é feita uma expansão do acesso para 
adequação do serviço.


2. Rede em dois estágios: concentração de acesso

Agora, vamos imaginar que o nosso roteador do Exemplo 1 não era assim tão 
perfeito; apesar de infinitamente rápido, ele possui limitações na sua 
capacidade de portas de acesso. Assim, torna-se necessário expandir a rede, 
fazendo a concentração dos acessos em outros equipamentos, tantos quanto 
necessário para interligar todos os clientes. O núcleo da rede, porém, 
continua bastante simples, com o nosso roteador central interligando todos os 
roteadores de acesso.

Considerando ainda que estamos falando de roteadores ideais, vemos que a 
única diferença para o cenário inicial está no dimensionamento dos troncos 
entre os concentradores de acesso e o roteador de núcleo. O tráfego nestes 
troncos depende da combinação do interesse de tráfego existente na rede, que 
pode ser expressa em uma matriz de tráfego simplificada, relacionando o 
volume de tráfego trocado entre dois clientes quaisquer. O estudo da matriz 
de tráfego pode indicar diferentes formas de estruturar e dimensionar os 
troncos da rede.

A capacidade total de cada tronco depende da combinação de clientes em cada 
roteador de acesso. Se modificarmos a forma como os clientes são agrupados, 
teremos um dimensionamento diferente. De forma genérica, seria ideal tentar 
agrupar os clientes que tem maior interesse comum de tráfego em um mesmo 
roteador de acesso. No entanto, isso nem sempre é possível, como veremos mais 
adiante (item 2.1).

Com uma rede mais complexa, utilitários como o MRTG começam a se mostrar 
limitados; afinal, eles apenas indicam se um tronco está sobrecarregado, mas 
não trazem nenhuma informação que possa permitir uma análise da arquitetura 
da rede (por exemplo, para tentar redistribuir os acessos minimizando a troca 
de tráfego entre os roteadores). Para compor a matriz de tráfego, outras 
ferramentas mais sofisticadas se fazem necessárias. As principais 
alternativas são as ferramentas de medição de tráfego baseadas em fluxos 
(flow-based accounting), das quais o NetFlow, criado originalmente pela 
Cisco, é um dos exemplos principais.

A medição do tráfego baseada em fluxos é muito flexível e poderosa, mas a 
quantidade de informações que podem ser coletadas também pode gerar mais 
problemas do que resolve. Para utilizar uma ferramenta como NetFlow, é 
preciso em primeiro lugar estabelecer cuidadosamente os critérios de medição:

- O NetFlow permite caracterizar o tráfego não somente pela sua origem x 
destino, mas por outras informações, como aplicaçao, tamanho dos pacotes, 
número de conexões TCP, etc. Em um primeiro momento, sugerimos que a análise 
seja feita considerando somente os endereços de origem e destino.

- A escolha dos pontos de coleta para a medida dos fluxos é importante, para 
evitar que os dados sejam computados em duplicidade na matriz de tráfego.

- O volume de informações geradas pelo NetFlow pode sobrecarregar não somente 
os roteadores, mas também a própria rede e os servidores que recebem os 
dados. De uma certa forma, o próprio NetFlow se torna uma das aplicações mais 
críticas da rede, afetando o resultado das medidas. 

- À medida que o volume de tráfego cresce, a quantidade de informações 
coletadas com o NetFlow cresce linearmente. No entanto, a quantidade de 
combinações de tráfego cresce geometricamente com o número de acessos. A 
partir de um certo ponto, a tendência é fazer a monitoração estatística dos 
fluxos. [obs: técnicas de coleta e concentração locais da medida podem dar 
mais fôlego ao NetFlow, mas o processo como um todo é matematicamente 
explosivo].


2.1. Concentração local de acessos

No mundo real, a forma de estruturar a rede com a concentração dos acessos 
está limitada por fatores práticos, que podem ser independentes da capacidade 
ou do número de portas dos roteadores. Um desses fatores é o custo do 
transporte entre os roteadores, que torna inviável economicamente a 
otimização da concentração de acordo com os dados da matriz de tráfego.

De uma forma geral, a modelagem da rede com a concentração local dos acessos 
também é feita com as mesmas ferramentas descritas no item (2). A principal 
diferença é reconhecer que nem sempre a melhor estrutura, conforme descrita 
pela matriz de tráfego, é viável, o que impõe mais limites às soluções 
viáveis para a rede.


3. Explodindo o núcleo da rede

Até agora, estamos considerando que a nossa rede está composta como uma 
estrela simples, e que o nosso roteador de núcleo concentra todo o tráfego, 
sem nenhum problema de performance. No entanto, essa topologia ideal também 
está sujeita aos limites do Mundo Real (tm). Os nossos roteadores de núcleo 
estão longe de serem ideais, tanto em desempenho como em confiabilidade. 
Assim, é importante distribuir a atividade do roteamento central em diversos 
equipamentos. Há várias formas distintas de atingir este objetivo.


3.1 Rede sem núcleo

Uma forma simplista de enxergar o problema é retirar completamente o núcleo 
da rede, de tal forma que os roteadores de acesso falam diretamente entre si. 
Neste caso, nossos roteadores de acessos estarão dispostos em uma topologia 
de malha densa, onde cada roteador possui troncos para todos os outros 
roteadores da rede. Esta topologia é bem mais complexa do que a nossa estrela 
simples do exemplo (2), e impõem novos desafios ao desenho da rede.

A principal ferramenta de planejamento de rede, neste caso, continua sendo a 
análise da matriz de tráfego, baseada nos dados do NetFlow ou outra 
ferramenta similar. Porém, o desenho em malha densa apresenta uma nova 
variável: a escolha do melhor caminho, baseada em um algoritmo de roteamento 
dinâmico.

Em uma rede em estrela (como no exemplo 2), não há alternativa de caminho. Na 
borda da rede, só há duas alternativas: comutação para uma interface local, 
ou para o núcleo da rede. A partir do momento que a rede possui uma malha, 
temos múltiplas rotas, e com isso múltiplas alternativas para escolher.

Em princípio, a topologia da rede em seu regime estável é relativamente 
simples. Supondo que todos os roteadores possuem conexão direta, temos apenas 
que dimensionar os troncos para a capacidade estimada de tráfego. No entanto, 
em caso de queda de um enlace qualquer, qual será o comportamento da rede?

Diferentemente de uma rede em estrela - onde a queda de um tronco significa 
uma interrupção de serviço - em uma rede em malha densa, teremos a escolha de 
uma nova rota para redirecionar o tráfego que antes passava pelo tronco que 
foi perdido. A rota de reserva tem que assumir o tráfego total, somando o 
tráfego do tronco que caiu ao seu próprio tráfego. Assim, o dimensionamento 
dos troncos para atuar como rota de reserva é um desafio importante. A 
princípio, qualquer tronco tem uma chance idêntica de falhar. Desta forma, 
temos que analisar todas as combinações possíveis de falha, para dimensionar 
os troncos de forma adequada.

Apesar de parecer óbvio, é importante não subestimar o problema apresentado. 
O dimensionamento incorreto da rota de reserva pode levar a uma situação de 
falha em cascata da rede; o tronco de reserva não consegue lidar com o volume 
total de tráfego, e em consequência começa a sobrecarregar outros pontos da 
rede. O planejamento da capacidade de reserva é uma atividade fundamental 
para evitar este problema.

Em muito casos, não é possível (ou interessante) criar uma estrutura de 
reserva para todas possibilidades de falha. Uma alternativa interessante é 
dotar a rede de um conjunto mínimo de troncos, bem dimensionados, e 
configurados de tal forma que o algoritmo de roteamento sempre escolha uma 
destas rotas para atuar como reserva. Este processo é possível com uma 
escolha adequada dos pesos e métricas do protocolo de roteamento. No entanto, 
para redes de grande porte, este é um trabalho que exige análise  
exaustiva, usando métodos matemáticos ou ferramentas de simulação 
especializadas.

A introdução do roteamento dinâmico é um dos elementos que permite dizer que 
passamos do simples dimensionamento de troncos para uma atividade de 'Traffic 
Engineering' para redes IP, segundo a definição mais aceita do termo. Daqui 
por diante, os outros exemplos apenas irão aprofundar nossa compreensão sobre 
o tema.


3.2 Camada de acesso + núcleo em malha densa

No mundo real, nem sempre é uma boa idéia compor a rede com apenas uma camada 
de roteadores fazendo as duas funções, acesso e núcleo. Várias razões podem 
ser citadas, entre elas:

- À medida que a rede cresce, o número de links da malha completa cresce 
geometricamente. A implantação de um núcleo de rede permite reduzir o tamanho 
da malha central da mesma; em consequência, também reduzimos a complexidade 
das decisões de roteamento.  

- A malha central pode ser otimizada para fazer o melhor uso dos recursos de 
transmissão existente entre os diversos pontos da rede.

- O núcleo e a borda da rede representam aplicações de natureza distinta, e 
que podem tirar vantagem de equipamentos com características diferenciadas. 

- Em termos administrativos, o isolamento do núcleo da rede se traduz em 
maior segurança e estabilidade.

Uma das consequências de um desenho em duas camadas, com um núcleo em malha 
densa, é a perda da ligação direta entre os roteadores de borda. Agora, a 
escolha do caminho entre dois pontos localizados na periferia da rede depende 
da participação dos roteadores de núcleo. Em redes de pequeno porte, este não 
chega a ser um problema sério. Porém, em redes de grande porte, é necessário 
um cuidado especial com a configuração das métricas do protocolo de 
roteamento utilizado no interior da rede, para garantir a convergência da 
rede para um desenho estável, onde os troncos tenham capacidade suficiente 
para o tráfego oferecido.


3.3. MPLS: Garantindo rotas pelo núcleo da rede

Em grandes rede IP, um dos principais desafios é garantir que o fluxo de 
dados siga pelos caminhos que foram previamente determinados pelo engenheiro 
de tráfego, com base nas informações da matriz. Em geral, isso é feito por 
meio do ajuste cuidadoso das métricas de roteamento. Porém, a complexidade 
dos algoritmos de roteamento e variedade imprevisível de situações que pode 
ocorrer torna este processo extremamente difícil de administrar.

Com o MPLS, temos uma ferramenta adequada para associar caminhos 
determinísticos a certos fluxos de dados. Utilizando um protocolo de 
roteamento especialmente adaptados (como o BGP4 ou OSPF), é possível fazer 
com que os roteadores de borda da rede vejam uma topologia em malha densa, 
sem que seja necessário provisionar manualmente cada um dos circuitos. Do 
ponto de vista dos roteadores de borda, a rede fica muito similar à 
apresentada em (3.1), mas aproveitando várias das otimizações apresentadas em 
(3.2).


4. Conclusão

Apresentamos neste artigo uma visão bastante simplificada de vários dos 
problemas que envolvem a atividade de Engenharia de Tráfego IP. Deixamos 
propositalmente de lado temas complexos, como diferenciação de serviços 
(DiffServ) e QoS (garantia de banda, latência, etc.); concentramos nossa 
atenção apenas no problema básico da escolha e dimensionamento das rotas. 
Nosso objetivo, antes de mais nada, é desmistificar o tema, mostrando uma 
visão prática, adequada à realidade brasileira, onde o crescimento das redes 
IP ainda é uma novidade. É importante deixar claro que Engenharia de Tráfego 
não é nenhuma tecnologia mágica, mas sim um conjunto de práticas e 
ferramentas, que só pode ser aplicada corretamente com uma compreensão clara 
do problema.

Esperamos que material seja útil, e que possa servir como base para 
discussões construtivas dentro do GT-ER. 


Carlos Ribeiro
CTBC Telecom