SRv6: o que é Segment Routing para IPv6 e por que os operadores já estão migrando
Nos fóruns de operadores de rede dos últimos anos, SRv6 passou de ser uma proposta de padrões a se tornar uma tecnologia em produção. No RIPE SEE 14 e no NANOG 96, múltiplos operadores apresentaram implementações reais: migrações de MPLS para SRv6, implantações de L3VPN sobre SRv6, e casos de uso de traffic engineering que antes requeriam infraestrutura MPLS complexa.
Para os operadores de rede na América Latina, o momento de entender SRv6 é agora: não para implantá-lo amanhã (na maioria dos casos ainda não é o momento), mas para incorporá-lo ao radar de planejamento e entender como afeta as decisões de equipamento e arquitetura que estão sendo tomadas hoje.
O problema com MPLS que SRv6 vem resolver
O MPLS tem mais de vinte anos como protocolo de transporte dominante nos cores dos ISPs. Funciona bem para o que foi projetado, mas tem fricções operacionais que se tornam mais visíveis à medida que as redes crescem:
Plano de controle complexo: O MPLS requer protocolos adicionais para a distribuição de labels: LDP (Label Distribution Protocol) ou RSVP-TE para traffic engineering, além do IGP subjacente. Cada um desses protocolos tem seu próprio estado, seu próprio processo de convergência, e seu próprio conjunto de ferramentas de debugging. A sobreposição de protocolos é uma fonte permanente de complexidade operacional.
RSVP-TE não escala bem: Para fazer traffic engineering em MPLS (desviar tráfego por caminhos específicos para otimizar a utilização), usa-se RSVP-TE. O problema é que RSVP-TE é um protocolo com estado em todos os nós da rota: cada roteador ao longo do LSP (Label Switched Path) deve manter informação sobre esse túnel. Em redes com muitos túneis de TE, isso se torna um problema de escala e estabilidade.
Interoperabilidade e extensões: Adicionar novos comportamentos em MPLS (novas ações em nós intermediários) geralmente requer novos tipos de labels ou novas extensões de protocolo, com o processo de padronização correspondente.
Visibilidade de ponta a ponta: No MPLS clássico, o cabeçalho visível nos nós intermediários é apenas a label. O debugger de tráfego vê a label mas não necessariamente o contexto completo do fluxo.
SRv6 não resolve todos esses problemas de uma vez, mas aborda os mais fundamentais de uma forma elegante.
O que é Segment Routing
Segment Routing é um paradigma de arquitetura de rede baseado em uma ideia simples: em vez de cada nó do caminho tomar decisões de forwarding baseadas em tabelas locais (o modelo MPLS clássico), o nó de entrada especifica o caminho completo codificando-o no próprio pacote.
O caminho é codificado como uma lista de segmentos. Cada segmento é uma instrução: “mande este pacote para este nó”, “use esta interface de saída”, “aplique este serviço”. Os nós intermediários simplesmente seguem as instruções do cabeçalho, sem necessidade de manter estado de sessão ou tabelas específicas para aquele fluxo.
Essa ideia tem duas implementações principais:
SR-MPLS (Segment Routing com labels MPLS): Os segmentos são codificados como labels MPLS padrão em um label stack. Reutiliza o dataplane MPLS existente, com as vantagens do plano de controle do SR. É o caminho de adoção para redes que já têm MPLS e querem migrar gradualmente.
SRv6 (Segment Routing sobre IPv6): Os segmentos são codificados como endereços IPv6 em uma extensão de cabeçalho especial chamada Segment Routing Header (SRH). Usa IPv6 como dataplane, eliminando a necessidade de MPLS completamente.
SRv6 em detalhe: como funciona
O Segment Routing Header (SRH)
SRv6 funciona adicionando ao pacote IPv6 uma extensão de cabeçalho especial: o SRH (Segment Routing Header, definido no RFC 8754). O SRH contém:
- Segment List: uma lista de endereços IPv6, ordenados de último a primeiro (o primeiro segmento a ser processado está no final da lista)
- Segments Left: um ponteiro para o segmento atualmente ativo
- Tag e Flags: metadados adicionais
O campo Destination Address do header IPv6 externo sempre aponta para o segmento atualmente ativo. Quando um nó processa o pacote, olha o Destination Address, executa a função associada a esse endereço, decrementa Segments Left, copia o próximo segmento para Destination Address, e reencaminha o pacote.
SIDs: os segmentos como funções
Cada endereço IPv6 na Segment List é um SID (Segment Identifier). O que torna SRv6 especial é que cada SID não é apenas um endereço de destino: é uma função que o nó que o possui deve executar quando recebe um pacote com esse endereço como Destination.
As funções mais importantes do plano de dados SRv6:
End (Endpoint): O nó é o endpoint do segmento. Processa o SRH, atualiza o ponteiro, e reencaminha para o próximo segmento. É o SID mais básico, equivalente a “passar por este nó”.
End.X (Endpoint com cross-connect de camada 3): Como End, mas além disso o nó deve reencaminhar o pacote por uma interface específica para um vizinho específico. Útil para traffic engineering: forçar que o tráfego tome um enlace particular.
End.DT4 / End.DT6 (Endpoint com decapsulação e lookup em tabela): O nó decapsula o cabeçalho SRv6 e faz um lookup do endereço interno em uma tabela de roteamento VRF específica. Esta função é a base para implementar L3VPN sobre SRv6 sem necessidade de MPLS.
T.Encaps (Trânsito com encapsulação): O nó de ingresso encapsula o pacote original dentro de um novo header IPv6 com SRH. Esta é a função que o head-end usa para iniciar um caminho SRv6.
A codificação da função dentro do endereço IPv6 não é arbitrária. O endereço SID tem estrutura:
uSID: resolvendo o problema de overhead
Uma crítica legítima do SRv6 em sua forma original é o overhead do cabeçalho. Cada SID na lista é um endereço IPv6 de 128 bits (16 bytes). Uma Segment List com 4 segmentos adiciona 64 bytes de overhead ao pacote. Para tráfego de baixa latência ou payloads pequenos, isso pode ser significativo.
A solução é o uSID (micro-SID), definido no RFC 9252 e adotado rapidamente pelos principais vendors. O uSID comprime múltiplos segmentos dentro de um único endereço IPv6 de 128 bits usando os blocos de 16 bits do campo de host:
Com uSID, um único endereço IPv6 pode codificar até 6 ou 7 segmentos (dependendo do tamanho do locator). O overhead cai dramaticamente: em vez de 64 bytes para 4 segmentos, você pode ter 4 segmentos em 16 bytes (um único endereço IPv6 adicional).
A maioria das implementações em produção hoje usa uSID. Huawei VRP 8.x+, Cisco IOS-XR 7.x+, e Nokia SR OS têm suporte a uSID em suas implementações SRv6.
Casos de uso operacionais em produção
L3VPN sobre SRv6 (SRv6 PE)
O caso de uso que mais está ganhando tração entre os ISPs é a implementação de L3VPN sobre SRv6, substituindo a combinação tradicional de MPLS + BGP VPNv4.
No modelo clássico MPLS L3VPN:
- O PE de ingresso faz um lookup no VRF do cliente e encapsula o pacote com duas labels MPLS: a label VPN (identifica o VRF no PE de egresso) e a label de transporte (encaminha o pacote pelo core MPLS até o PE de egresso).
No SRv6 L3VPN:
- O PE de ingresso faz um lookup no VRF do cliente.
- Encapsula o pacote com um novo header IPv6 cujo Destination é o SID
End.DT4do PE de egresso para aquele VRF específico. - O pacote transita pelo core usando o IGP normal (o Locator do SID é roteável).
- O PE de egresso recebe o pacote, reconhece o SID
End.DT4, decapsula o cabeçalho SRv6, e faz lookup no VRF correspondente.
Não há LDP. Não há RSVP. Não há distribuição de labels. O estado da VPN está encapsulado no endereço IPv6 do SID.
Traffic Engineering sem RSVP-TE
Com SR-TE (Segment Routing Traffic Engineering), o traffic engineering é implementado sem o overhead de estado do RSVP-TE. Em vez de sinalizar um túnel end-to-end com estado em cada nó, o head-end simplesmente inclui na Segment List a sequência de nós ou enlaces por onde quer que o tráfego passe.
Se você quer que o tráfego de um cliente tome o caminho A-B-D em vez do caminho mais curto A-C-D, o head-end constrói uma Segment List com [End.X de A para B, End de D]. O nó intermediário B não precisa saber nada sobre o fluxo: apenas processa o SRH.
Tráfego cliente VRF-Cliente-1:
[End.X(A→B), End.X(B→D), End.DT4(D, VRF-Cliente-1)]
Tráfego geral best-effort:
[End.DT4(D, tabela global)] (caminho mais curto por IGP)
Service Function Chaining
SRv6 é especialmente adequado para inserir funções de rede (firewalls, DPI, CGNATs, proxies) no caminho do tráfego de forma programática. Cada função é um SID que o tráfego deve visitar. O head-end constrói a Segment List incluindo o SID da função.
SRv6 e os vendors: estado atual de suporte
Huawei VRP
Huawei tem um dos suportes SRv6 mais completos entre os vendors ISP. O equipamento NE series (NE40E, NE8000) suporta SRv6 desde VRP 8.x em produção, incluindo:
- SRv6 BE (Best Effort, sem TE) com End e End.DT4/DT6
- SRv6 TE Policy com segmentos de nó e adjacência
- SRv6 L3VPN (BGP VPNv4/VPNv6 sobre SRv6)
- EVPN sobre SRv6
- uSID
Os switches de acesso e distribuição (CloudEngine series) têm suporte mais limitado. Para um ISP que usa Huawei no core e distribuição, o cenário mais realista de adoção inicial é SRv6 nos PE e P do core, com o acesso mantendo-se em MPLS ou roteamento plano durante uma fase de transição.
Cisco IOS-XR
Cisco foi um dos primeiros a implementar SR-MPLS em produção e estendeu esse suporte a SRv6 no IOS-XR 7.x:
! Habilitar SRv6 no Cisco IOS-XR
segment-routing
srv6
locators
locator CORE
micro-segment behavior unode psp-usd
prefix 2001:db8:1::/48
!
!
!
!
! Configurar SRv6 para BGP VPNv4
router bgp 65001
address-family vpnv4 unicast
vrf-table-label
!
!
vrf CLIENTE-1
rd 65001:1
address-family ipv4 unicast
segment-routing srv6
locator CORE
alloc mode per-vrf
!
!
!
!
Nokia SR OS
Nokia construiu seu portfólio ISP (série 7750 SR, 7450 ESS) com Segment Routing como eixo central há anos. O suporte SRv6 no SR OS é extenso e inclui as funções avançadas de uSID e traffic engineering.
Quando faz sentido considerar SRv6 para um ISP na LATAM
SRv6 não é para todos os ISPs hoje, e é importante ser honesto sobre isso. As condições em que SRv6 faz sentido considerar no curto prazo:
Você tem equipamento de core que já o suporta: Se seu core roda em Huawei NE, Cisco ASR 9000 / NCS, ou Nokia 7750, o hardware provavelmente suporta SRv6 com uma atualização de software. O custo de ativação é baixo.
Está planejando substituir o core de MPLS: Se você está em um ciclo de refresh de equipamento, o momento de avaliar SRv6 é o design da nova arquitetura. É muito mais difícil inserir SRv6 em uma rede MPLS existente do que planejá-lo desde o início.
Tem serviços VPN que quer simplificar: Se opera L3VPN para clientes corporativos e o plano de controle MPLS é uma carga operacional permanente, SRv6 L3VPN pode simplificar significativamente a operação eliminando LDP e RSVP.
Está considerando ofertas de conectividade SD-WAN ou serviços diferenciados: SRv6 é o plano de transporte natural para orquestração de paths programáticos, que é a base técnica de SD-WAN e slicing de rede.
As condições em que SRv6 provavelmente não é a prioridade correta agora:
- A rede ainda roda MPLS estável com equipamento de mid-life.
- A equipe técnica não tem experiência com IPv6 em produção (SRv6 requer maturidade em IPv6 como pré-requisito).
- Não há caso de negócio concreto que justifique o esforço de adoção.
O que vemos no campo
Nos projetos de consultoria com ISPs na América Latina, SRv6 aparece frequentemente como uma tecnologia que as equipes técnicas querem entender mas que ainda não estão pilotando. O principal bloqueio geralmente não é a tecnologia em si nem o equipamento (que em muitos casos já o suporta), mas a curva de treinamento e a falta de referência operacional local.
A adoção vai acelerar nos próximos dois a três anos à medida que os grandes carriers regionais (que já estão pilotando ou já têm SRv6 em produção) comecem a oferecer serviços que pressupõem SRv6 no acesso. Os ISPs regionais que entenderem a tecnologia vão conseguir se integrar melhor a esses ecossistemas.
Conheça mais sobre nossos serviços de design de arquitetura de rede e consultoria técnica.
Quer avaliar SRv6 no contexto da sua rede?
Podemos revisar sua arquitetura atual, identificar se seu equipamento está pronto para SRv6, e projetar um roadmap de adoção que se adapte à sua realidade operacional.
Vamos conversar sobre sua arquitetura →
Tem perguntas sobre SRv6, MPLS ou arquitetura de rede? Escreva para [email protected] — respondemos todas as mensagens.