Introducao ao 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

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.

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
Artigo Redes MPLS para Provedores
Artigo Engenharia de Tráfego com MPLS TE
Artigo Introdução ao IPv6 Provider Edge over MPLS 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).
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:

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" 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?

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.

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:

Aprimoramento drástico das capacidades de Gerenciamento de Falhas (detecção, verificação, isolamento, recuperação e notificação de falhas)
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)
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

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!

https://youtu.be/NqC9nGFVkUU

Até o próximo artigo aqui no BPF!