2/10/22, 11:48 PM Introducao ao Unified MPLS - Wiki BPF

Introducao ao Unified MPLS

Índice
Introdução ao Unified MPLS / Seamless MPLS
Nota sobre direitos autorais, termo de uso e isenção de responsabilidade
Sobre o Unified MPLS
Os Desafios das Redes Tradicionais com MPLS
Escalabilidade
Tamanho do domínio de roteamento interior:
Complexidades associadas ao próprio MPLS:

Benefícios quanto à Adoção do Unified MPLS

Os Componentes e o Funcionamento do Unified MPLS
Domínios de Protocolos de Roteamento do tipo "Interior Gateway Protocol" (IGP)
Domínios Label Distribution Protocol (LDP)
BGP-4 RFC 3107 ("Carrying Label Information in BGP-4")
BGP PIC (Prefix Independent Convergence)
MPLS no Acesso
Loop-Free Alternate ("Caminho Alternativo sem Loop") e Remote Loop-Free Alternate
BGP Filtering
Protocolos Operation, Administration, and Maintenance (OAM) e correlatos
SDN-enabled Carrier Ethernet: a Direção e Evolução das Arquiteturas Unified MPLS
Vídeo Demonstrativo do Unified MPLS

Introdução ao Unified MPLS / Seamless MPLS

Nota sobre direitos autorais, termo de uso e isenção de responsabilidade

Consulte os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de
destinação profissional.

Autor: Leonardo Furtado ([Link]

Este artigo tem por objetivo a dissertação objetiva da solução Unified MPLS ("MPLS Unificado") ou Seamless MPLS em infraestruturas de redes de
operadores de telecomunicações.

Sobre o Unified MPLS

As infraestruturas de redes dos operadores de telecomunicações, sejam estes organizações com ofertas multisserviços, ou simplesmente provedores de
acesso de Internet, tem sofrido muitos desafios associados a diversos de seus Indicadores-Chave de Desempenho (do inglês Key Performance Indicators
(KPIs)) de cunho tecnológico, tais gestão de Incidentes, Desempenho, Escalabilidade, Usabilidade, Segurança, Gerenciamento, etc., além de seus
respectivos níveis de serviços, dentre outras áreas de aspectos técnicos, operacionais e processuais. Por vários anos muitos operadores de redes
compreendem que diversos destes desafios podem ser bastante atenuados com a adoção de tecnologias mais sofisticadas e apropriadas para fomentar
melhores resultados sobre estes indicadores. Por exemplo, infraestruturas construídas com tecnologias baseadas no MPLS tendem a simplificar
drasticamente a complexidade operacional nas questões de despesas operacionais (OPEX), manutenção, planejamento de capacidades, suporte técnico,
resolução de incidentes, provisionamento inteligente de clientes e serviços, gerenciamento e afins; até mesmo saneando questões financeiras com
iniciativas tais como a maximização da utilização dos recursos de rede e infraestruturas, redução de custos com técnicas mais apropriadas para
gerenciamento de falhas, consumo racional de enlaces de comunicação de dados por meios de seleção inteligente de caminhos, ações de engenharia de
tráfego, etc. Apenas para pontuar algumas situações aqui.

Portanto, o MPLS por muitos anos tem sido fundamental para permitir o crescimento dos operadores de redes de telecomunicações sem que
necessariamente ocorra um crescimento proporcional da complexidade operacional com as necessidades de expansão e manutenção estes ambientes. A
principal proposta das arquiteturas baseadas no MPLS é a de promover maior fluidez nos serviços de telecomunicações através de ações mais
operacionalmente atenuadas sobre estes KPIs supracitados, e fazendo isto com excelente relação de qualidade x custos.

[Link] 1/7
2/10/22, 11:48 PM Introducao ao Unified MPLS - Wiki BPF
Apesar do MPLS como um todo ter sido extremamente útil ao longo de todo esse tempo, fundamental até, em diversos projetos de redes em operadores
de telecomunicações, há também desafios associados ao próprio conceito de escalabilidade dos backbones dos operadores. Ou seja, o MPLS, quando
comparado aos modelos mais legados de infraestruturas comutadas (L2) e/ou roteadas pelo IP "nativo" (L3), indiscutivelmente apresenta indicadores
bem mais interessantes para o operador. No entanto, os backbones de grandes operadores possuem restrições e limitações que não são integralmente
saneadas com os projetos tradicionais envolvendo as tecnologias baseadas no MPLS. E é exatamente neste ponto onde vemos o MPLS Unificado como
uma solução para destravar o crescimento das redes destes operadores para níveis brutalmente escaláveis.

Este artigo não tecerá comparativos entre arquiteturas de redes tradicionais e o MPLS. Inclusive assumo aqui que você já saiba o suficiente sobre o que é
o MPLS, suas vantagens, benefícios, etc. Caso você não conheça apropriadamente sobre o tema, recomendo que em primeiro momento você desprenda o
seu tempo com a leitura dos seguintes artigos, já publicados e disponíveis na Wiki do Brasil Peering Forum (BPF):

Artigo Fundamentos de Roteamento para Provedores ([Link]

Artigo Redes MPLS para Provedores ([Link]
Artigo Engenharia de Tráfego com MPLS TE ([Link]
Artigo Introdução ao IPv6 Provider Edge over MPLS e 6VPE ([Link]
_e_6VPE)

Os Desafios das Redes Tradicionais com MPLS

O Multiprotocol Label Switching (MPLS) tem estado no mercado há bastante tempo e promovido muitos benefícios para operadores multisserviços e
ISPs. Na maioria dos casos as abordagens clássicas com as tecnologias baseadas no MPLS tem atendido sem quaisquer complicações para as operações
do provedor - desde que boas práticas sejam observadas aqui - portanto estes desafios não são necessária ou exatamente aplicáveis para o universo dos
provedores de acesso de Internet de pequeno e médio portes, mas, sim, uma realidade, quase que um fato, para grandes operadores de telecomunicações.

Mesmo que estes desafios a serem discutidos não façam parte da realidade de seu provedor, conhecer estes desafios, assim como o próprio MPLS
Unificado, certamente será de grande valia para amplificar o seu entendimento sobre como funcionam as redes baseadas no MPLS.

Os principais desafios são:

Escalabilidade
A capacidade natural da rede de expandir sem que haja modificações significativas em seu projeto original.

Tamanho do domínio de roteamento interior:

Em função da elevada quantidade de equipamentos L3 nativos, enlaces de interconexão entre elementos de rede e seus respectivos prefixos de rede IPv4
e IPv6, podendo, em alguns operadores, representar um volume muito alto de rotas instaladas na tabela de roteamento (Routing Information Base ou
"RIB"), resultando ainda na consequente programação - integral ou seletiva - destes prefixos nas estruturas de encaminhamento de pacotes baseadas em
hardware.

Mesmo em equipamentos modernos, que escalam bastante em suas tabelas de roteamento, em alguns casos podendo acomodar mais de 20 milhões de
rotas na RIB, a quantidade massiva de rotas derivadas de protocolos de roteamento interiores (Interior Gateway Protocol ou "IGP") na RIB não é
recomendada, e isto por algumas razões óbvias. Na primeira delas, os protocolos IGP não escalam para redes muito grandes, e isto não possui uma
relação direta com o hardware empregado e sim com a maneira em que estes protocolos de roteamento interiores operam. Como regra geral, recomenda-
se que a tabela de rotas IGP de um backbone não possua mais que 40 mil rotas (ex: OSPF ou IS-IS), mesmo em alguns casos com números homologados
em 100 mil rotas IGP, e este número pode ser um pouco maior ou bem menor, variando de acordo com o equipamento utilizado. A segunda razão, de
certa forma conectada à primeira, está relacionada ao aumento expressivo do processamento dos equipamentos em função de computações excessivas
realizadas sobre os bancos de dados dos protocolos Link-State tais como o OSPF e o IS-IS, mesmo em projetos que já obedeçam uma boa abordagem de
segmentação por áreas - as quais servem justamente para minimizar o montante de informações sobre os links das redes e reduzir os impactos das
computações necessárias com algoritmos tipicamente onerosos, como é o caso do Dijkstra, usado por ambos o OSPF e o IS-IS. Quanto maior for o LSDB
das áreas participantes de um projeto com o OSPF ou o IS-IS, assim como a frequência em que são disseminadas as modificações de estados de links
nestas áreas, mais frequentemente ocorrerão recomputações destes banco de dados. E isto não é bom. Há mecanismos periféricos para controlar os
acionamentos de computação do LSDB, mas isto não impede determinados problemas.

Complexidades associadas ao próprio MPLS:

Fornecendo aqui uma lista resumida de situações onde redes MPLS muito grandes apresentam muitos desafios para os operadores.

Elevada complexidade tecnológica e operacional para assegurar a rápida convergência (desejado aqui 50ms, ou, no máximo, sub-segundo) com
tecnologias clássicas do MPLS Traffic Engineering (TE) tais como o Fast Reroute (FRR).
A necessidade por adoção de mecanismos para a melhor integração entre a infraestrutura MPLS e as tecnologias de enlace de dados (L2).

[Link] 2/7
2/10/22, 11:48 PM Introducao ao Unified MPLS - Wiki BPF
Os desafios relacionados ao provisionamento de serviços fim a fim, mesmo em ambientes onde o MPLS já reduz os pontos operacionais de
intervenção humana (quais elementos de rede L3 precisam ser configurados para ativar um determinado cliente ou serviço?).
Aumento da complexidade do gerenciamento de incidentes nestes ambientes.
A complexidade quanto a utilização dos mecanismos tradicionais fim-a-fim para ações de convergência e a elasticidade da infraestrutura.
Em ambientes bem grandes, a inevitável necessidade pela fragmentação do domínio IGP do operador em domínios IGP melhores, e fazer a devida
integração.

Benefícios quanto à Adoção do Unified MPLS

A abordagem do MPLS Unificado aproveita a maior parte das iniciativas já estabelecidas em ambientes que contam com as práticas do MPLS tradicional,
só que fornecendo maior e melhor elasticidade, escalabilidade, convergência, segurança e gerenciamento. Esta solução consolida os benefícios e esforços
do consagrado MPLS e as modificações contextuais necessárias para a unificação de toda esta infraestrutura MPLS:

Maior escalabilidade com o particionamento do domínio IGP: uma das iniciativas do MPLS Unificado é particionar um domínio IGP grande em
domínios IGP menores, afetando diretamente as questões de escalabilidade (bancos de dados IGP bem menores; redução dos prefixos IGP na
RIB, consequentemente na FIB também) e menor impacto no processamento dos equipamentos com a redução dos ciclos de processamento
envolvendo os algoritmos de computação sobre as bases de dados (ex: LSDB) destes protocolos de roteamento IGP.
Rápida convergência: a combinação dos benefícios da redução de rotas IGP das tabelas de roteamento com recursos de Fast Reroute, além de
outras iniciativas, promovem tempos de convergência mais condizentes com os níveis de serviço do operador, além de reduzir muito drasticamente
as instabilidades provocadas por eventos de convergência dos domínios IGP, mesmo que estes sejam grandes.
Simplificação operacional nas ações de resolução de incidentes: com domínios IGP menores, em combinação com outras boas práticas a
serem adotadas em cada domínio IGP, fica mais fácil e mais rápido não somente isolar o problema, mas assegurar que, de acordo com a qualidade
do projeto técnico geral, distúrbios provocados em um segmento não promovam indisponibilidades. Eventos de convergência de um domínio ficam
restritos/confinados no domínio em que ocorreram, promovendo maior estabilidade para toda a infraestrutura e para os serviços fim-a-fim.
Maior facilidade de integração com tecnologias de Acesso: embora isto não seja uma premissa exclusiva do Unified MPLS, pois é algo que
pode ser feito também nos projetos tradicionais com o MPLS, fica mais fácil e bem mais escalável estender o MPLS para o perímetro de Acesso do
operador, resultando no transporte do MPLS fim-a-fim.
Provisionamento mais simplificado de serviços: incluindo as diversas modalidades de L3VPN e L2VPN, e sem mecanismos InterAS e sem a
necessidade de "costurar" os pseudowires das L2VPN via procedimentos tais como Pseudowire Stitching.
Redução mais significativas dos pontos operacionais de intervenção humana: para o provisionamento de clientes e de seus serviços
contratados, o que maximiza os níveis de serviço, simplifica as ações de diagnósticos e suporte, e reduz custos operacionais.

Topologia ilustrando o conceito de Unified MPLS

Os Componentes e o Funcionamento do Unified MPLS

O MPLS Unificado comumente emprega os seguintes componentes, podendo haver distinções em algumas áreas funcionais em razão da disponibilidade
tecnológica e recursos suportados pelos equipamentos de seu fornecedor ("vendor") de escolha:

[Link] 3/7
2/10/22, 11:48 PM Introducao ao Unified MPLS - Wiki BPF

Componentes empregados pelo Unified MPLS

Domínios de Protocolos de Roteamento do tipo "Interior Gateway Protocol" (IGP)

Simplificando alguns entendimentos aqui: o protocolo padrão adotado pelos provedores/operadores em seus ambientes de backbone é o OSPF e/ou o IS-
IS. Tanto para o IPv4 quanto para o IPv6. Fato. Na relação PE-CE, em serviços de L3VPN, outros protocolos podem ser usados tais como RIPv2/ng, ou
instâncias separadas/dedicadas de OSPFv2/v3, ou o EIGRP, ou até mesmo o BGP. Mas foquemos aqui apenas na parte do backbone e dos protocolos
interiores usados para interconectar os perímetros de Acesso, Pré-Agregação, Agregação e Core. O protocolo de roteamento interior usado nestes
cenários é o OSPF ou o IS-IS.

Ambos os protocolos OSPF e IS-IS possuem diversos mecanismos e práticas que são usadas para fomentar maior escalabilidade dos ambientes, ou seja,
acomodar redes bem grandes. Dentre as iniciativas temos o próprio conceito do projeto de áreas (ex: multiarea OSPF), além de recursos para maximizar
as capacidades de convergência durante eventos de falhas, throttling de informações de estados de links (ex: LSAs ou TLVs), pacing de computação do
LSDB, etc. Estes são capacidades naturais, recursos nativos destes protocolos de roteamento.

O MPLS Unificado vai além das ferramentas e recursos nativos destes protocolos e estabelece um novo paradigma: "quebraremos" estes domínios IGP
grandes em domínios IGP menores, mais escaláveis, simplificados, eficientes e estáveis. Pelas razões já discutidas anteriormente neste artigo. O que a
solução MPLS Unificado tem que fazer em primeiro momento: interconectar estes domínios IGP pelo MPLS.

Domínios Label Distribution Protocol (LDP)

À exemplo do caso dos domínios IGP, o mesmo precisará ser feito com o protocolo LDP. Uma (muito) breve recapitulação: o protocolo LDP é responsável
por alocar e distribuir labels em uma rede MPLS. Os roteadores formam vizinhanças entre as suas interfaces Loopback (sejam entre vizinhos diretamente
conectados ou por regime multihop com targeted hello). Os labels são sempre gerados com interesse nos prefixos IGP publicados nas tabelas de
roteamento (RIB) dos roteadores, ou seja, não há a geração de labels referentes à rotas BGP (sugiro consultar o artigo "Redes MPLS para Provedores (htt
ps://[Link]/w/Redes_MPLS_para_Provedores)" para maiores esclarecimentos).

Portanto o LDP é um protocolo fundamental para viabilizar o que é desejado com arquiteturas MPLS. Uma vez que o domínio IGP foi "quebrado" em
domínios IGP menores, o mesmo deve ocorrer com relação ao LDP: cada domínio será um domínio IGP+LDP independente, ou seja, todas rotas OSPF a
serem publicadas na tabela de roteamento de um roteador de um determinado domínio são rotas OSPF apenas daquele domínio, assim como os labels
que deverão ser alocados e distribuídos (apenas labels de rotas IGP daquele domínio), além de mantidos em suas tabelas de labels (ex: LIB ou nome
similar usado pelo seu vendor).

BGP-4 RFC 3107 ("Carrying Label Information in BGP-4")

Se unificássemos os domínios IGP com o uso de um protocolo de roteamento interior (ex: OSPF), na verdade estaríamos novamente centralizando todos
os prefixos IGP sob um único domínio, justamente o oposto do que queremos fazer e justamente o oposto da proposta do MPLS Unificado, certo?

[Link] 4/7
2/10/22, 11:48 PM Introducao ao Unified MPLS - Wiki BPF
No entanto é necessário haver a comunicação entre usuários e clientes espalhados nos múltiplos domínios presentes na arquitetura MPLS Unificada,
mais precisamente, claro, nos perímetros de Acesso da comunicação fim-a-fim pretendida, pois é normalmente no Acesso que conectamos a última milha
de clientes e assinantes. Como viabilizar o roteamento de assinantes posicionados em redes de Acesso presentes em domínios IGP distintos, uma vez que
não há rotas IGP trocadas entre estes dois domínios? A resposta para isto está definida justamente neste RFC 3107, pois, além da redistribuição das rotas
IGP de cada domínio para o BGP, com o posterior repasse desses prefixos entre as sessões iBGP do domínio original, deverá haver um label associado a
cada prefixo, onde o conjunto prefixo + label deverá ser trocado entre as sessões iBGP que interconectam os domínios do cenário de MPLS Unificado.

A solução proposta implementa o protocolo de roteamento BGP-4 para a troca de labels entre os domínios IGP+LDP distintos, pois é um protocolo que
possui excelente escalabilidade quanto ao tamanho de sua tabela de rotas e a própria RIB, além de suportar múltiplas famílias de endereços (IPv4
Unicast, IPv6 Unicast, IPv4 e IPv6 Multicast, VPNv4, VPNv6, L2VPN...). E, com este RFC 3107, permitir a troca de labels entre os roteadores que deverão
interconectar estes perímetros.

Dentro dos domínios as relações entre os roteadores - vizinhanças iBGP - podem ser feitas por full mesh ou, melhor ainda, por clusters de refletores de
rotas (Route Reflectors), os quais eliminam as exigências por full mesh no Sistema Autônomo (AS) do provedor. Isto faz da solução como um todo
bastante escalável no ponto de vista do BGP, e permite, inclusive, combinar estas relações iBGP dos domínios com iniciativas de BGP-Free Core nos
roteadores Provider (P-routers, ou roteadores de Core apenas, os quais ficariam isentos de BGP e operariam somente por IGP+LDP em seus respectivos
domínios). Ou seja, MPLS Unificado considerando BGP-Free Core (nos P-routers) fica bastante escalável, mesmo!

BGP PIC (Prefix Independent Convergence)

O BGP PIC não é um recurso digamos... mandatório ... para a concepção do MPLS Unificado, mas certamente um recurso muito apreciável, bem vindo
mesmo, para os projetos com esta solução. O BGP PIC é conhecido também pelo nome de BGP Fast Reroute (BGP FRR).

O BGP PIC promove essencialmente o seguinte benefício: diminuição muito considerável do tempo de convergência do plano de dados. Possui duas
variações:

BGP PIC Core: reduz o tempo de convergência no plano de dados quando um roteador de backbone (P-router) fica indisponível e o protocolo de
roteamento IGP precisa encontrar um novo caminho interno para promover o roteamento recursivo referente aos NEXT_HOP das rotas BGP.
BGP PIC Edge: reduz o tempo de convergência no plano de dados quando um roteador PE vier a falhar e todo o tráfego precisar comutar para
outro roteador PE, o que passa a ser bem interessante para clientes dual/multi-homed com aquele provedor.
Em outra oportunidade publicarei um artigo na Wiki do BPF para dissecar apropriadamente sobre recursos tais como o BGP PIC.

MPLS no Acesso
Embora não seja uma exclusividade do Unified MPLS, ter o MPLS no Acesso permite eliminarmos domínios L2 grandes comumente encontrados no
perímetro de Acesso do projeto Hierárquico, Modular e Estruturado do provedor. Mais precisamente, o uso do MPLS no Acesso promoverá dois
benefícios muito úteis para o provedor:

Saneamento dos problemas de escalabilidade e convergência de domínios L2, em especial àqueles operados por protocolos de resiliência que
notoriamente possuem problemas com diâmetros excessivos (STP e suas variações, REP, EAPS, G.8032).
Reduzirá substancialmente os pontos operacionais de intervenção humana, que determinam quais equipamentos precisam ser configurados para
viabilizar a ativação de um cliente/assinante ou serviço para o mesmo.
Portanto, o MPLS no Acesso é uma iniciativa que deve ser observada para termos um legítimo MPLS Unificado!

Loop-Free Alternate ("Caminho Alternativo sem Loop") e Remote Loop-Free Alternate

Outra tecnologia que não é necessariamente mandatória para o Unified MPLS em si, mas, de certa forma, muito interessante para os propósitos e
benefícios que esperamos que infraestruturas de MPLS Unificado forneçam para os nossos indicadores e níveis de serviços.

Nada contra a tecnologia MPLS Traffic Engineering, em particular de seu estupendo recurso Fast Reroute (MPLS TE FRR), muito pelo contrário! Sou
eternamente grato em todos os projetos onde tive que enfrentar desafios de congestionamentos na infraestrutura com as soluções de MPLS TE, em
alguns projetos com milhares de túneis de TE implementados, contando ainda com as configurações FRR!

No entanto, dentre as várias vantagens que desejamos no projeto do Unified MPLS, uma delas tem total relação com a simplificação do projeto técnico no
geral ou como um todo, certo? Pois bem, ao fragmentarmos o domínio IGP+LDP em domínios IGP+LDP menores, para necessidades e efeitos de melhor
estabilidade, escalabilidade, convergência, gerenciamento, manutenção, etc., ao mesmo tempo, infelizmente, tornamos a infraestrutura mais complexa
para a admissão de túneis de tráfego com tecnologias tais como o MPLS TE. Ou seja, fica mais complexo trabalhar com o MPLS Traffic Engineering, e
neste caso em particular, com a questão de proteção dos túneis de TE com o mecanismo Fast Reroute (FRR).

Uma ótima solução para necessidades de rápida recuperação de falhas em ambientes de MPLS Unificado está numa capacidade que obviamente deve ser
suportada por todos os equipamentos roteadores participantes: o LFA e R-LFA.

[Link] 5/7
2/10/22, 11:48 PM Introducao ao Unified MPLS - Wiki BPF
Como o foco deste artigo não é esmiuçarmos o LFA/R-LFA , até mesmo porque isto poderá ser tema de um artigo específico em ocasião próxima,
permita-me simplificar o entendimento:

Ambas as tecnologias MPLS TE Fast Reroute (FRR) e Loop-Free Alternate com Fast Reroute (LFA FRR) tem como proposta a (muito) rápida
convergência em cenários de falhas de roteadores ou de enlaces da rede. Ou seja, se um enlace ficar indisponível, todo o tráfego que percorria aquele
caminho é imediatamente (aproximadamente 50 milissegundos) transferido para um caminho alternativo pré-computado e isento de loop.

O LFA/R-LFA possui algumas vantagens quando comparado ao RSVP-TE (usado pelo MPLS TE clássico) sendo que, uma delas, obviamente, é dispensar
por completo o uso do protocolo RSVP. Ou seja, não é necessário sinalizar isto pela rede, pois todo o mecanismo de recuperação de falhas e a pré-
computação de caminhos alternativos isentos de loop deve ser feito pelo próprio IGP (ex: OSPF). Quando o LFA está habilitado, o IGP computa não
somente a melhor rota para cada destino, mas já deixa pronto caminhos alternativos isentos de loop presentes tanto na RIB quanto na FIB, porém não
encaminha o tráfego para os caminhos alternativos até que ocorra uma falha na rede.

Ou seja, o LFA/R-LFA promove o mesmo tempo de convergência mediante falhas do RSVP-TE FRR (50ms) e serve para o mesmo propósito.

Se a sua infraestrutura já conta com RSVP-TE FRR, você não precisará do LFA/R-LFA.

É importante frisar que o MPLS Traffic Engineering e seu recurso Fast Reroute (FRR), e até mesmo o LFA/R-LFA da maneira que
estamos discutindo aqui neste artigo, enfim, são tecnologias que serão gradual e inevitavelmente substituídas por tecnologias mais
modernas e para os mesmos propósitos, como é o caso do Segment Routing para ações de label switching e engenharia de tráfego, além
de sua extensão Segment Routing Topology Independent Loop-Free Alternate; o famoso SRTILFA, para combinar label
switching + engenharia de tráfego + fast reroute, tudo sendo operado por um único protocolo, o próprio IGP (OSPF ou IS-IS)! E isto
será obviamente tema de discussão aqui na Wiki do BPF em breve!

BGP Filtering
Não somente a parte ou a questão dos filtros e tudo mais, mas as ferramentas e procedimentos óbvios e complementares do BGP-4 serão exaustivamente
necessários para os projetos de infraestrutura com o MPLS Unificado, à exemplo do que ocorre tipicamente nos projetos envolvendo o BGP. Isto dispensa
muitos comentários aqui nesta seção sobre o BGP. Ou seja, observância de como o BGP seleciona os melhores caminhos para cada destino, conhecimento
pleno de seus atributos, domínio sobre as ferramentas para filtros e seleção de caminhos, com ou sem a manipulação de atributos; uma consistente
política de roteamento BGP (incluindo um plano decente com uso de Communities) tanto para o backbone quanto para os clientes, etc.

Protocolos Operation, Administration, and Maintenance (OAM) e correlatos

Ainda não será desta vez que esmiuçarei o OAM em um artigo e/ou vídeo para o Brasil Peering Forum (BPF), mas isto certamente está no radar para um
futuro próximo!

O OAM em si não é uma tecnologia "mandatória" para o MPLS Unificado, mas a sua cautelosa adoção poderá promover muitos benefícios nas áreas
associadas ao Gerenciamento de Falhas do provedor (Incidentes, Diagnósticos, Reparos, etc.). O OAM não é um protocolo em si, e sim um framework
que combina diversos protocolos, tecnologias e ferramentas, devidamente estruturadas para maximizar as capacidades operacionais do operador de
redes de telecomunicações. Alguns dos componentes do OAM:

Ethernet Connectivity Fault Management (CFM)

Link OAM
Ethernet LMI
MPLS OAM
Information Model Objects (IMOs)
Os componentes combinados do OAM promovem três macro benefícios para o provedor:

1. Aprimoramento drástico das capacidades de Gerenciamento de Falhas (detecção, verificação, isolamento, recuperação e notificação de falhas)
2. Aprimoramento drástico das capacidades de Gerenciamento de Desempenho (medições de perdas de símbolos, quadros, pacotes; medições de
latência unidirecional e fim-a-fim, assim como o jitter, medições da disponibilidade/SLA)
3. Aprimoramento excepcional das capacidades de Gerenciamento de Configurações (ex: aprovisionamento de serviços)
Qual a relação entre as tecnologias OAM e o MPLS Unificado? Não há uma dependência de mecanismos OAM com as tecnologias primárias que
fomentam o Unified MPLS, é verdade, mas a integração de todo o framework OAM para uma infraestrutura de MPLS Unificado promoverá benefícios
excepcionais para o operador, em particular sobre os benefícios supracitados.

SDN-enabled Carrier Ethernet: a Direção e Evolução das Arquiteturas Unified MPLS

[Link] 6/7
2/10/22, 11:48 PM Introducao ao Unified MPLS - Wiki BPF
Caso você tenha se surpreendido de alguma forma com a solução Unified MPLS e se interessado pelas tantas tecnologias aqui discutidas, saiba que já
existe em produção em alguns operadores justamente a evolução desta abordagem! Sim, já temos algo "melhor", tanto em desenvolvimento continuado
quanto em uso em algumas dos principais operadores, mas deixo bem claro que isto não elimina a realidade, utilidade ou qualquer possibilidade para a
adoção do MPLS Unificado nos moldes discutidos neste artigo, considerando a realidade da grande maioria de operadores e provedores que possam
beneficiar-se desta abordagem.

Alguns fabricantes lideres de indústria possuem soluções Carrier Ethernet completamente turbinadas por conceitos de redes definidas por software
(Software-Defined Networking ou "SDN"), contando com amplas capacidades de automação e orquestração, e empregando ainda menos componentes.
Um destes fabricantes, a Cisco, tem em seu portfólio a solução SDN-enabled Agile Carrier Ethernet (ACE).

Você provavelmente deve estar confuso, mas escrever um artigo sobre o Unified MPLS foi fundamental para deixar o caminho pavimentado para que
outros artigos possam ser publicados futuramente explicando as evoluções das arquiteturas Carrier Ethernet e dos conceitos de MPLS unificado. Mas
qual é a diferença entre o Unified MPLS discutido aqui, neste artigo, e uma solução como a arquitetura ACE da Cisco, ou solução similar de outro
fabricante, como a Juniper, por exemplo? Na verdade, são muitas. As necessidades, porém, são quase imutáveis, sendo as mesmas áreas de interesse; os
mesmo desafios, ou seja, os mesmos problemas. O que o ACE (ou similar fornecido pelo seu fabricante (vendor) de escolha) propõe-se a fazer são as
mesmas coisas ou atender as mesmas necessidades dos modelos aqui discutidos neste artigo, só que empregando menos protocolos (basicamente quase
tudo sendo feito por um único protocolo, o IGP padrão da rede), em combinação com componente tais como Orquestradores de Serviços de Rede (ex:
solução Cisco NSO), Path Computation/WAN optimization (ex: solução PCE/XTC), controladoras SDN de abordagem aberta ou comercial, em
combinação com clássicos tais como BGP, LDP, Segment Routing, SRTILFA, e os serviços L2VPN e L3VPN transportados no topo destes. Esta evolução
dos ambientes Carrier Ethernet turbinados por tecnologias combinadas com MPLS unificado tem como principal objetivo promover os seguintes:

Abstração de serviços e de seus modelos

Abstração de rede com mecanismos diferenciados para seleção inteligente de caminhos, convergência, e modelagem da engenharia de rede e de
tráfego
Abstração de aparato físico (dispositivos), tais como controladores, equipamentos, seus protocolos e outras propriedades
Simplificação e otimização dos protocolos requeridos para o atendimento das necessidades discutidas neste artigo
Melhor integração entre as redes ótica + Ethernet + IP
Estou colocando o tema aqui para o roadmap de um novo artigo em breve na wiki do BPF!

Vídeo Demonstrativo do Unified MPLS

Agora que você concluiu a leitura deste artigo - espero que tenha gostado do formato e da objetividade! - que tal conhecermos na prática como funciona
um ambiente desses? Essa é a proposta do vídeo que está disponível no canal do YouTube do Brasil Peering Forum. Confira!

[Link]

Até o próximo artigo aqui no BPF!

Autor: Leonardo Furtado ([Link]

Disponível em "[Link]

Esta página foi modificada pela última vez em 12 de maio de 2020, às 03h08min

[Link] 7/7