Exibir código-fonte para Engenharia de Trafego com MPLS TE

=== Introdução: a necessidade por engenharia de tráfego e a relação com o MPLS TE ===
O '''''Multiprotocol Label Switching Traffic Engineering (MPLS TE)''''' é uma tecnologia que foi criada para sanar uma deficiência inerente do próprio modelo de roteamento instaurado e suportado pelo protocolo IP. Essencialmente, ou resumidamente, o MPLS TE propõe-se a resolver os seguintes grandes desafios em temos técnicos e que são decorrentes do roteamento IP tradicional.

=== Uma revisão de conceitos fundamentais sobre determinação de caminhos e encaminhamento de pacotes ===
Para que este artigo consiga efetivamente esclarecer os conceitos de engenharia de tráfego e como o MPLS Traffic Engineering pode contribuir para diversas situações de congestionamentos do provedor, ou seja, atingindo o nosso objetivo aqui, torna-se necessário uma breve revisão de fundamentos do roteamento IP. O motivo desta "revisão de fundamentos" é que o MPLS TE implementa diversos mecanismos e há vários requisitos para o seu funcionamento, sendo que, para todos os efeitos, o profissional de redes deverá ser bom conhecedor de operações básicas do funcionamento tanto de roteadores quanto do próprio roteamento IP.

À título de revisão de alguns fundamentos de programabilidade das estruturas de encaminhamento/comutação de pacotes, esclareço a seguir:
* '''Distâncias Administrativas''' definem o critério de confiabilidade da origem da informação no entendimento do software do roteador. Cada protocolo de roteamento, ao selecionar os seus melhores caminhos para as redes conhecidas, oferta estes caminhos para processos que gerenciam a tabela de roteamento (chamada de "RIB"). Neste momento, o roteador atribui uma "Distância Administrativa" (critério de confiabilidade) sobre as opções de caminhos ofertadas pelo protocolo de roteamento. É o chamado "Administrative Distance". Protocolos mais sofisticados ou mais inteligentes tendem a possuir um "AD" melhor, o que caracteriza maior confiabilidade sobre a informação recebida. Por exemplo, uma rota para a rede 172.16.1.0/24 por OSPF é preferida sobre uma rota 172.16.1.0/24 por RIPv2.
** Opções de rotas oriundas de diversos protocolos de roteamento sobre uma mesma rede de destino: o critério de desempate e seleção do melhor caminho para a efetiva publicação deste na tabela de roteamento se dá justamente pelo comparativo entre as Distância Administrativas apresentadas.
* '''Métricas''' definem como cada protocolo de roteamento seleciona as melhores rotas para os destinos conhecidos da rede. Cada protocolo entende a rede de um jeito bem particular. Por exemplo, o RIP emprega como métrica o ''hop count'', o OSPF emprega o ''cost'' como métrica, enquanto o EIGRP emprega uma métrica composta por vários elementos, mas ''bandwidth'' e ''delay'' são as únicas fatoradas por padrão. Já o BGP, por sua vez, possui um extenso critério de seleção do melhor caminho (''best path'') com base em atributos de vetores de caminhos e 11 critérios adotados para a seleção do melhor caminho.
** Quando há duas ou mais opções de caminhos para uma mesma rede oriundas de um mesmo protocolo de roteamento, o próprio protocolo de roteamento selecionará o melhor caminho com base na melhor métrica. Por exemplo, o RIP entende que uma rota para a rede 172.16.1.0/24 com 5 saltos de diâmetro é uma opção melhor do que uma rota para a mesma rede com 10 saltos de diâmetro. Na mesma moeda, o OSPF considera a melhor opção para uma determinada rede de destino aquela que apresentar o melhor (menor) valor em seu ''custo''.
* '''Incidência sobre o prefixo mais específico''' é efetivamente o único critério adotado pelos roteadores para selecionar qual deverá ser a rota a ser utilizada para o encaminhamento de um pacote, independentemente da origem da informação. É o que determinará, dentre todas as opções de rotas publicadas na tabela de roteamento, qual destas rotas será utilizada para encaminhar um determinado pacote.
** Por exemplo, para encaminhar o pacote para o endereço IP de destino 172.16.1.1 o roteador preferiria a rota RIPv2 172.16.1.0/25 ao invés da rota OSPF 172.16.1.0/24.

=== Limitações nativas do roteamento IP ===
O roteamento baseado no protocolo IP possui alguns “defeitos”, conforme esclarecido a seguir:

==== Comportamento natural “salto-a-salto” - também conhecido como "''per-hop behavior''" -  e orientado somente ao endereço IP de destino. ====
O roteamento IP unicast tradicional não se importa com o endereço IP de origem descrito no cabeçalho IP do pacote, exceto, de certa forma, quando implementando mecanismos adicionais para o processamento de pacotes, como o é o caso do ''unicast Reverse Path Forwarding'' (uRPF) ou de uma ''Policy-Based Routing'' (PBR), e afins. Suprimamos por completo mecanismos e recursos adicionais aqui para melhor entendimento, e observemos somente a questão do roteamento IP em si. O roteamento IP está realmente ligado ao conceito de "para onde" os pacotes deverão ser encaminhados, ou seja, uma intenção exclusiva de análise do endereço IP de destino citado no cabeçalho IP do pacote recebido. E é justamente esta característica natural do roteamento IP que fomenta o surgimento de alguns problemas associados aos congestionamentos nos enlaces de rede.

==== Utilização ineficiente dos recursos de rede disponíveis ====
Os congestionamentos que comumente experimentamos em uma rede IP são causados justamente pelo próprio fato do roteamento IP sempre utilizar os melhores caminhos, cujos critérios do que seria tratado como "melhor caminho" variam de acordo com o entendimento de cada protocolo de roteamento empregado e com o que de fato está publicado nas estruturas de comutação do roteador (ex: rotas na tabela de roteamento (RIB) e, consequentemente, as entradas na tabela de encaminhamento (FIB)). E isto foi esclarecido no início deste artigo.

Consequentemente, a existência de poucos links saturados ou congestionados atendendo a maior parte do tráfego, enquanto, ao mesmo tempo, havendo outras opções de links que poderiam ser utilizados para encaminhar tráfego mas que estão com baixa utilização (enlaces subutilizados).

No que tange ao encaminhamento de pacotes pelo roteador em uma rede, o critério principal de seleção de uma rota para o efetivo encaminhamento deste tráfego será a rota que for a mais específica, conforme já citado. Novamente, e por exemplo, suponhamos que o endereço IP de destino citado no cabeçalho IP de um determinado pacote fosse “10.1.1.1”, e o roteador possuísse duas rotas possíveis e que atendessem ao propósito: 10.1.1.0/28 via RIP e 10.1.1.0/24 via OSPF. A opção /28 é mais específica que a opção /24 e, portanto, esta rota e a sua adjacência associada serão utilizadas. Se, por exemplo, tivéssemos três opções de rotas, sendo a primeira 10.1.1.0/24 pelo RIP, e 10.1.1.0/24 pelo OSPF com custo de 100 e 10.1.1.0/24, também pelo OSPF, com custo de 200, a única rota que existiria na tabela de roteamento seria a rota OSPF 10.1.1.0/24 com custo de 100.

Ao compreendermos que o roteamento IP encaminha tráfego sempre orientado ao endereço IP de destino, e independente de qual protocolo de roteamento forneceu esta rota, então qual seria exatamente o problema discutido aqui? Um problema conhecido chamado "''The Fish Problem''"!
[[Arquivo:Bpf-roteamento-mplste-1.png|centro|miniaturadaimagem|650x650px|The Fish Problem]]

==== A caracterização do "The Fish Problem" ====
* Caminhos alternativos e redundantes interconectando dois pontos de interesse para o tráfego no backbone.
* O protocolo de roteamento escolhe apenas o melhor caminho. Em alguns casos, mais de um caminho, desde que as rotas possuam custos iguais (ECMP). Em exceções ao ECMP, onde suportado, caminhos ativos sobre rotas de custos desiguais.
* O roteador sempre encaminha o tráfego sobre o melhor caminho selecionado.
* Em muitos casos, o melhor caminho não reúne condições plenas de acomodar toda a carga de tráfego que lhe é ofertado. Portanto, fica saturado/congestionado, afetando significativamente a qualidade das conversações sobre a rede.
* Ao mesmo tempo, diversos caminhos alternativos e não selecionados ficam praticamente ociosos.
Tudo isto ocorre por que o roteamento IP sempre encaminhará o tráfego na rede em mecanismo salto-a-salto ao longo deste melhor caminho, enquanto as outras opções ou alternativas de caminhos não são utilizados ou devidamente aproveitados. Se a quantidade de tráfego ofertado sobre este "''melhor"'' caminho for superior à capacidade de algum dos links ou interfaces envolvidas nesta melhor rota, haverá congestionamentos e fatalmente descartes de pacotes na rede, dependendo das condições de utilização da rede, o que resultará em baixo desempenho geral, e baixo ''throughput'';
# Consequentemente, o chamado “melhor caminho” fica saturado, sobrecarregado;
# Ao mesmo tempo em que os caminhos alternativos não são utilizados ou ficam muito subutilizados;
# O mapeamento do tráfego de rede sobre os recursos disponíveis é muito ineficaz;
# As consequências disto tudo são reclamações, problemas, impactos, e o seu planejamento de capacidades fica complexo e oneroso...
Esta insuficiência de recursos que caracteriza o "The Fish Problem" resultam em congestionamentos de duas formas:
* Quando os recursos de rede por si só são '''insuficientes''' para acomodar a carga oferecida.
* Quando os fluxos de tráfego são mapeados '''ineficazmente''' sobre os recursos disponíveis.

=== O que é Engenharia de Tráfego e quais são os motivadores para a adoção de tecnologias tais como o MPLS Traffic Engineering? ===
A principal proposta das ações de engenharia de tráfego é a redução dos custos gerais de operação através do uso mais eficiente dos recursos de rede, incluindo os custos decorrentes dos enlaces contratados, equipamentos, interfaces e demais componentes. Essencialmente as ações de engenharia de tráfego atendem as necessidades de prevenção de situações onde algumas partes da rede ficam super-utilizadas (congestionadas), enquanto outras partes da rede permanecem sub-utilizadas., e, com isto, garantir o caminho mais apropriado para algum ou todo o tráfego da rede, além de permitir a implementação de mecanismos para a proteção do tráfego contra falhas na rede.

Com boas ações de engenharia de tráfego é possível aprimorar substancialmente o SLA da infraestrutura em combinação com outras técnicas para Quality of Service (QoS) e afins. 

Há várias formas de implementarmos a engenharia de tráfego numa rede, sendo que, para cada opção disponível, há vantagens e desvantagens:
# '''Ampliar a capacidade dos circuitos''' seria uma ação simples e óbvia! Congestionou? Aumente a capacidade do circuito! No entanto, você terá que investir substancialmente para aumentar a capacidade da rede, incluindo enlaces, interfaces, módulos, até mesmo equipamentos inteiros... enquanto uma boa parte da infraestrutura se mantém (ou continua!) relativamente ociosa ou desperdiçada. 
# '''Técnicas clássicas de controle de congestionamentos''', tais como queueing, policing, shaping, etc., onde aplicáveis, em combinação com a ampliação da capacidade da rede.
# '''Manipulação de métricas dos protocolos de roteamento''' é outra iniciativa bastante conhecida, mas, no entanto, especialistas tratam isto como medida "engessada". Afinal de contas, isto tornaria o projeto técnico razoavelmente mais complexo na medida em que filtros e diversas ferramentas periféricas sejam utilizadas para fazer com que o tráfego da rede desejado flua pelos caminhos planejados. Estes tipos de iniciativas tendem a provocar efeitos colaterais bastante indesejados: conserta-se um problema e provoca-se ao mesmo tempo outros dez problemas!
# '''Implementar tecnologias mais atraentes como o MPLS Traffic Engineering (MPLS-TE) tradicional''' ou os adventos mais recentes, tais como Segment Routing, SRv6 e TILFA, tendem a resolver de forma mais efetiva os problemas de congestionamentos e proteção de tráfego das redes IP, ou seja, são consideradas ferramentas mais sofisticadas, granulares, flexíveis e melhor administráveis. 
Como o foco deste artigo é o MPLS Traffic Engineering tradicional, foquemos somente nesta tecnologia. Em outras oportunidades serão apresentadas e discutidas outras tecnologias, mais recentes inclusive, sobre este tema.

O paradigma corrente do roteamento baseado no protocolo IP é centrado no objetivo "''destination-based''", o que se prova claramente inadequado, pois a computação de rotas baseada somente na métrica IGP não é o suficiente e o suporte para "''explicit routing''" (''source routing'') nativamente não é uma opção viável. Alguns engenheiros de redes costumam a adotar algumas ações paliativas para o problema do congestionamento dos enlaces de rede, tais como manipulações de métricas dos IGP, emprego de rotas estáticas ou com Policy-Based Routing (PBR). Estas iniciativas agregam mais complexidades do que benefícios além de tornar a recuperação controlada de enlaces backup e recuperação de falhas na rede uma tarefa bem mais difícil.

O MPLS TE apresenta:
* Modelo efetivo de ''explicit routing''
* Introdução ao chamado ''constraint-based routing''
* Suporte a mecanismos para a admissão de túneis de tráfego
* Ótimas capacidades de proteção de túneis e, consequentemente, do tráfego da rede (''Fast Reroute''); ótimo recurso "''Make-Before-Break''"
* Emprego do protocolo RSVP-TE para o estabelecimento dos LSP
* Emprego de extensões do OSPF / ISIS para os anúncios dos atributos de links
* Eliminação da necessidade de modificações nas métricas do IGP da rede, o que por sua vez previne o surgimento de diversos problemas e complexidades bastante indesejadas
* Os túneis de tráfego são definidos somente nos roteadores denominados ''headend''. São a entrada para os túneis de tráfego, os quais, aliás, só são configurados e conhecidos por este equipamento.
** Os demais equipamentos da rede MPLS sequer conhecem a presença de um túnel de tráfego definido em um ''headend'' (ex: roteador PE ou roteador P).
** O que torna o projeto bastante previsível e de melhor administração na questão de gerenciamento de túneis de tráfego. 
* É importante que frisar que os túneis de tráfego são '''''unidirecionais'''''! Isto significa que o administrador da rede deverá observar o comportamento simétrico desejado para a engenharia de tráfego. Ou seja, a construção de túneis de tráfego nos dois sentidos da comunicação pretendida.

=== Visão geral dos requisitos para o MPLS Traffic Engineering ===
Um projeto bem sucedido para a adoção do MPLS TE deverá observar diversos fatores críticos para o seu sucesso, dos quais destaco alguns a seguir:
* '''Projeto de infraestrutura com abordagem hierárquica, modular e estruturada'''. Infraestruturas de telecomunicações funcionam bem melhor em ambientes onde há as chamadas "camadas de função", que são os perímetros de rede com missão bem específica para os diversos serviços e componentes orquestrados. Por exemplo, ''Acesso'', ''Pré-Agregação/Agregação'', ''Core''. O protocolo de roteamento OSPF inclusive foi projetado para funcionar melhor sobre este tipo de disposição topológica.
* '''Plano de endereçamento IP adequado.''' A alocação e distribuição dos endereços de rede dos enlaces internos do provedor, além de interfaces loopback e blocos IP para as regiões ou áreas da rede onde há a concentração de serviços e de assinantes. Observe as boas práticas quanto a alocação e distribuição dos endereços IP em sua rede!
* '''Protocolo de Roteamento IGP suportado.''' Apenas os protocolos de roteamento OSPF e ISIS são suportados, pois foram os únicos que receberam as devidas extensões para engenharia de tráfego (LSAs no OSPF e TLVs no ISIS). Não bastando, o próprio projeto técnico relacionado ao protocolo de roteamento deverá ser construído com base nas boas práticas. Tanto o OSPF quanto o ISIS executam uma computação diferenciada, modificada, para acomodar as extensões para fins de engenharia de tráfego.
* '''Matriz de tráfego detalhada.''' Como implementar o TE sem que o engenheiro da rede saiba o que precisa ser feito ou manipulado? Quais são os reais interesses para as aplicações a serem atendidas com o MPLS TE?
* '''MPLS Label Switching'''. O MPLS TE é uma das soluções que rodam no topo do MPLS label switching tradicional.
* '''Protocolo para Alocação e Distribuição de Labels''': em uma rede MPLS tradicional, o ''Label Distribution Protocol (LDP)'' é utilizado para distribuir os labels entre os roteadores vizinhos. No entanto, em uma rede onde todas as interfaces habilitadas para o MPLS (geralmente "core-facing") sejam também desejadas para a engenharia de tráfego com MPLS TE (cenário de full mesh entre roteadores Provider Edge (PE)), o protocolo aqui poderá ser exclusivamente o ''Resource Reservation Protocol (RSVP)'' que, apesar de ter sido herdado do modelo ''IntServ'' (QoS), não faz hard-QoS e serve no MPLS TE somente para control plane para as funções a seguir:
** Estabelecimento e manutenção dos ''Label Switched Paths'' (LSPs) para os túneis de tráfego.
** Criação e manutenção dos estados ao longo da rede MPLS (alocação de banda por prioridade e por interface dos roteadores participantes).
** Implementa objetos específicos para estas funções, tais como LABEL_REQUEST (PATH) LABEL (RESV), EXPLICIT_ROUTE, RECORD_ROUTE (PATH/RESV) e SESSION_ATTRIBUTE (PATH).
* OBS: em redes onde os túneis de tráfego são estabelecidos somente entre roteadores Provider (P-routers, ou roteadores dedicados no backbone), certamente será exigido, além do RSVP-TE para o MPLS-TE, o LDP para as demais funções de ''label switching''.
[[Arquivo:Bpf-roteamento-mplste-2.png|centro|miniaturadaimagem|650x650px]]

Neste tipo de arquitetura, ''labels'' são atribuídos para túneis, os quais representam o caminho (LSP) através da rede, e o encaminhamento de pacotes na rede MPLS é baseado nestes labels (não há lookup Layer 3). Este conceito de Traffic Tunnels (MPLS-TE tunnels) foi introduzido para superar as limitações do roteamento "hop-by-hop" do IP, onde o túnel pode atuar como uma agregação de fluxos de tráfego que são colocados em um LSP de MPLS comum. Estes fluxos são encaminhados então através da rede do provedor, particularmente através dos caminhos desejados pelo engenheiro da rede, respeitando-se as premissas por SLA e QoS almejadas. Os túneis de tráfego são objetos roteáveis e, em contextos operacionais, um túnel de tráfego pode ser movido de um caminho para outro. 

Atributos são associados aos túneis de tráfego para influenciar diversas de suas características. Alguns exemplos aqui:
* '''Parâmetros de Tráfego''' – recursos requeridos para o túnel (ex: banda requerida).
** Banda Máxima – o montante de banda disponível em um determinado link.
** Banda Máxima Reservável por Túnel
* '''Seleção e Gerenciamento de Caminhos''' – os "''paths''" podem ser computados administrativamente ou pelo IGP suportado.
** Métrica específica do Constraint-based – métrica default do TE.
** Caminhos Explícitos
** Seleção Dinâmica de Caminhos em combinação com a métrica default do TE e atributos de túneis e de links.
* '''Afinidade de Classe de Recursos''' – incluir ou excluir certos links para determinados túneis de tráfego.
** String de Afinidade de Links – para permitir ao operador a inclusão ou exclusão seletiva de links da computação do TE para um determinado traffic tunnel.
* '''Adaptação''' – o túnel de tráfego deverá ser reoptimizado?
* '''Prioridade e Preempção''' – importância de um túnel de tráfego e a possibilidade de assumir os recursos utilizados por outros túneis de tráfego
* '''Resiliência''' – comportamento desejado em situações de falhas na rede, sejam links ou equipamentos.
Ultimamente, o engenheiro da rede então mapeia os tipos de tráfego desejados para os túneis de tráfego correspondentes a serem estabelecidos e conforme os critérios e objetivos do projeto técnico, os quais deverão ser derivados a partir da ampla compreensão das matrizes de tráfego elaboradas. O mapeamento do tráfego para os túneis de TE poderá ocorrer das seguintes formas:
# '''Rota estática''', apontando as redes de destino desejadas para a interface Tunnel no roteador ''headend''.
# '''Policy-based Routing (PBR)''' ou ferramenta similar, permitindo, no roteador ''headend'', identificar qual deverá ser o tipo de tráfego a percorrer o túnel.
# '''Auto-route Announce''' (Cisco), '''IGP-Shortcut''' (Juniper e Huawei), onde, automaticamente, todas as redes atrás do roteador ''tailend'' serão automaticamente associadas à interface Tunnel no roteador ''headend'', logo, portanto, o tráfego de interesse para estas redes de destino será encaminhado através deste túnel.
# '''Forwarding Adjacency''' (Cisco), '''Advertise-LSP''' (Juniper), permite anunciar a interface Tunnel como enlace ''ponto-a-ponto'' numa rede OSPF, o que, por sua vez, permitiria melhor seleção de caminhos e o efetivo ''load balancing'' dos links internos do backbone por roteadores não participantes do MPLS TE, especialmente em ambientes de interconexão de POPs.
E, fundamental deixar bem destacado:

'''"O foco do MPLS TE não é sobre o congestionamento criado como um resultado de rajadas de curto prazo, mas sim sobre problemas de congestionamentos que são prolongados ou persistentes'''."

Espero ter esclarecido algumas coisas importantes sobre o MPLS TE: não faz mágica e não é a solução para congestionamentos de curto prazo decorrentes de eventos inesperados. O MPLS TE é eficiente nas questões de planejamento de capacidades e congestionamentos persistentes, além de servir como excelente ferramenta para maior disponibilidade do backbone.

Aproveite a oportunidade para conferir um '''''mind map''''' que resume não somente os componentes do MPLS TE, mas das aplicações gerais baseadas no MPLS!

https://wiki.brasilpeeringforum.org/images/1/1b/MPLS_Mind_Map_-_Leonardo_Furtado.pdf

'''Autor: Leonardo Furtado'''

<nowiki>*</nowiki> Imagens empregadas neste artigo foram inspiradas em apresentações do Cisco Live.
[[Categoria:Roteamento]]