Resumo

  • O RFC 4090 trata de LSPs RSVP-TE explicitamente roteados. O head-end solicita proteção e insere as restrições FAST_REROUTE sem modificação; o PLR calcula ou seleciona e ativa localmente um backup apenas para um LSP elegível com estado de backup disponível; o merge point reúne o tráfego ao LSP protegido.
  • Quando o salto protegido falha, o PLR redireciona tráfego de dados e controle para um detour ou bypass. O objetivo normativo para a redireção de um detour é da ordem de dezenas de milissegundos. Detecção é uma entrada, não autoridade de reparo: BFD ou outra evidência de vivacidade não escolhe sozinha o caminho de recuperação.
  • O one-to-one detour cria um LSP de backup separado para cada LSP protegido, aumentando estado e recursos por LSP. O shared facility bypass protege vários LSPs elegíveis com um túnel compartilhado, reduzindo construções repetidas, mas compartilhando capacidade, merge point e destino de falhas comuns. No facility bypass, o PLR empilha rótulos: aplica o rótulo do LSP protegido e faz push do rótulo do túnel bypass; o merge point remove o contexto do bypass e continua no LSP protegido.

Autoridade separada

Somente o head-end LER insere o objeto FAST_REROUTE, que não deve ser alterado por LSRs downstream. O head-end solicita proteção local, pode solicitar registro de rótulos e proteção de link ou de nó, e mantém setup priority, holding priority, requested bandwidth, hop limit e filtros de afinidade ou atributos de link. No RSVP-TE, setup priority define se uma nova sessão pode obter recursos por preempção; holding priority define se os recursos reservados podem ser preemptados. Se a largura de banda não estiver disponível e não houver reserva elegível de menor prioridade para preempção, surge um PathErr.

O PLR tem autoridade estreita e temporária. Ele considera node protection, requested bandwidth, eventual garantia de banda e os filtros do FAST_REROUTE; depois calcula ou escolhe um backup elegível e o ativa diante da falha. A indicação local-protection-available só significa disponibilidade quando existem um caminho de backup e o estado de encaminhamento necessário, conforme esclarece a Errata 4203 verificada. Após ativar a proteção, o PLR marca local-protection-in-use e deve notificar o head-end com um PathErr. O head-end continua responsável pela sinalização de um LSP mais adequado e pela reotimização global.

O merge point não é um novo decisor de caminho. Ele recebe o tráfego desviado, remove o contexto de facility bypass e o devolve ao LSP protegido. Isso é diferente da autoridade do PLR para ativar o reparo e da autoridade do head-end sobre as restrições ponta a ponta e a reotimização.

Escala, custo e retorno

O one-to-one oferece uma semântica por LSP mais direta, mas consome mais estado de backup, rótulos e sinalização. O facility bypass reduz construções por LSP, mas faz com que capacidade, limpeza de estado ou compatibilidade de um bypass e de seu merge point afetem mais LSPs. A capacidade protegida pode ser reservada ou, segundo as prioridades, tornar-se preemptível. Na análise de Elias Ward, o preço do reparo rápido inclui banda, pilha de rótulos, estado do plano de controle, compatibilidade e cobertura de testes; o compartilhamento troca escala por dependência comum.

O RFC 4090 distingue global reversion, em que o head-end reotimiza os LSPs afetados com uma visão ampla, de local reversion opcional no PLR, e recomenda o modo global revertive. Com recursos em flapping, a reversão local pode acrescentar interrupções. Sem reparo local pré-estabelecido, o contrafactual é esperar a convergência do head-end ou do roteamento, com potencial para mais perda de pacotes e continuidade mais lenta. Porém, um reparo sem restrições ou com estado antigo pode conservar uma reserva errada, esconder cobertura incompleta e exceder sua premissa em uma segunda falha.

O RFC 8796 atualiza o facility backup do RFC 4090 com sinalização summary-FRR, destinada a reduzir a troca de mensagens entre PLR e merge point e a pressão de escala e latência do plano de controle quando muitos LSPs compartilham um bypass. O RFC 9705 atualiza a proteção por facility para que manutenção de estado e limpeza de estado obsoleto não dependam de timeouts curtos de refresh; acrescenta procedimentos explícitos de capacidade, adjacência e teardown para operação independente de refresh. Essas atualizações não significam suporte em toda implementação.

Fixtures de verificação

  1. Fixture de sinalização: no PATH, confirme que o FAST_REROUTE é inserido somente pelo head-end LER; registre setup/holding priority, bandwidth, hop limit, método de proteção e afinidade, e prove que LSRs downstream não o alteram.
  2. Fixture de recursos: use LSPs com capacidade e prioridades conhecidas para testar banda suficiente, insuficiente, preempção permitida e proibida. Compare sucesso ou PathErr com requested bandwidth e holding priority.
  3. Fixture de topologia: derrube separadamente um link protegido e um nó protegido; verifique que link protection e node protection não são confundidos. Registre PLR, próximo salto de backup, merge point e pilha de rótulos.
  4. Fixture de estado: compare backup e encaminhamento completos com o caso em que há apenas a flag de sinalização. Verifique local-protection-available; após a falha, verifique local-protection-in-use, PathErr e o estado observado pelo head-end.
  5. Fixture de método: para a mesma facility, crie one-to-one detour e shared facility bypass; compare estado por LSP, push/pop de rótulos, capacidade compartilhada e o alcance de uma segunda falha.
  6. Fixture de reversion: produza recuperação de recurso, flapping curto e falhas consecutivas; compare global reversion com local reversion e procure estado obsoleto após a limpeza.
  7. Fixture de atualização: em combinações de nós com e sem suporte a summary-FRR do RFC 8796 e aos procedimentos refresh-independent do RFC 9705, observe volume de mensagens, negociação de capacidade, adjacência e teardown. Não presuma suporte.

Os fatos acima estão limitados ao que os textos do RFC Editor e o registro de errata verificada sustentam diretamente. Custos, incentivos operacionais, beneficiários e riscos são análise de Elias Ward, não evidência de implantação. As fontes não comprovam quais fornecedores ou operadores usam cada método, suas margens atuais de capacidade, tempos medidos de reparo, incidentes ou resultados para clientes. O comportamento diante de falhas simultâneas, flapping, estado obsoleto e interoperabilidade entre versões permanece desconhecido.

Fontes