Resumo

  • Um ponto de junção que protege um nó mantém o estado do LSP ao receber um Conditional PathTear compatível. Um receptor sem essa função pode ter de apagar o estado e encaminhar uma remoção normal.
  • Remote PathTear permite ao ponto de reparo encerrar a espera no ponto de junção antes da conclusão da sinalização de proteção.
  • Suporte anunciado incorretamente pode deixar resíduos por muito tempo ou eliminar cedo demais uma reserva válida. A compatibilidade precisa ser avaliada por direção e por LSP.

O estado que ficou pode estar correto

Depois de uma falha, a tabela de um roteador continua contendo uma reserva. O vizinho já removeu seu próprio estado e enviou uma mensagem de retirada. É tentador interpretar o que ficou como resíduo. Mas o receptor pode estar cumprindo uma obrigação de proteção: apagar agora destruiria o estado necessário para receber o caminho de contingência.

O RFC 9705, publicado em março de 2025 na trilha de padronização, trata precisamente dessa diferença. Seus exemplos são situações definidas pela especificação, não relatos de incidentes. O nome PathTear não basta para decidir se um estado deveria desaparecer.

A proteção por desvio compartilhado do RFC 4090 recorria ao vencimento de atualizações periódicas para limpar parte dos estados antigos. Se uma remoção normal chegasse antes da sinalização de contingência, poderia eliminar o estado necessário no ponto de junção. Alongar os intervalos criava o problema oposto: estados abandonados permaneceriam por mais tempo. RFC 9705 torna explícitas as razões para manter e os eventos que encerram essa manutenção.

Quem pode conservar uma reserva

O caminho com comutação de rótulos é o LSP. RSVP mantém estado de caminho, PSB, e estado de reserva, RSB. O ponto de reparo local, PLR, conduz o caminho protegido por um desvio; o ponto de junção, MP, conecta a proteção à continuação do LSP.

O LP-MP protege o enlace a partir do salto anterior. O NP-MP corresponde ao desvio realizado dois saltos antes, contornando o nó intermediário. São funções de um LSP específico. Um mesmo equipamento pode exercer ambas, sem que isso autorize manter o estado de qualquer outro caminho.

Para reconhecer a função, o receptor precisa de uma associação B-SFRR-Ready correspondente que o identifique como destino do desvio, uma adjacência de sinalização Node-ID ativa com o PLR indicado e o anúncio da capacidade RI-RSVP desse PLR. A associação vem do RFC 8796. Suportar sua sinalização resumida não equivale a suportar os novos procedimentos de remoção. Identidades ausentes entre áreas IGP podem exigir o retorno às regras de compatibilidade.

A autorização de manter o estado, portanto, não aparece depois da falha por conveniência. Ela decorre de uma relação que já havia sido estabelecida e cujas condições ainda precisam valer.

A condição muda a obrigação

Na topologia A–B–C–D usada pelo RFC, A dispõe de um desvio que evita B e termina em C. C é o NP-MP de A. Se o enlace A–B falha e B não é um MP desse LSP, B remove PSB e RSB. Quando a entrada solicitou proteção de nó e B não recebeu um PathTear de montante, ele envia um Conditional PathTear.

C preserva o estado do LSP. Um receptor que não seja NP-MP deve removê-lo, retirar o objeto opcional CONDITIONS e enviar um PathTear normal adiante. O objeto não deve circular sem que cada destinatário resolva a condição prevista.

Existe ainda uma regra para a origem da mensagem. Se o vizinho não anunciou suporte aos novos procedimentos, o Conditional PathTear recebido é tratado como normal: o estado é apagado e a remoção propagada. Um objeto opcional não substitui a negociação de capacidade.

CONDITIONS utiliza a classe 135 e o C-Type 1. Seu indicador de condição de junção seleciona o tratamento por função; sem o indicador, aplica-se o tratamento normal. A regra detalhada de recepção especifica NP-MP. O rótulo abreviado “MP” não concede a todos os pontos de junção a mesma obrigação de retenção.

Preservar o caminho e revogar o antigo protetor

Suponha que B também tivesse anunciado uma proteção de nó que terminava em D. Ao apagar seu próprio estado, B perde o fundamento dessa antiga relação. C, porém, precisa continuar preservando o LSP para A.

C remove do Path a associação B-SFRR-Ready de B e envia a atualização a D. D apaga o estado remoto de caminho correspondente a B. Se a retirada dessa associação for a única alteração, não propaga o Path mais adiante. A reserva útil fica, enquanto a informação sobre um protetor que já não pode agir é retirada.

O estado remoto é uma referência para uma futura remoção explícita. Seu RSVP_HOP usa o endereço Node-ID do PLR. Não é uma segunda reserva de cliente, e sua exclusão não deve ser confundida automaticamente com a exclusão dos PSB e RSB protegidos.

Reter também tem limites. Um LP-MP pode manter o estado após a falha do enlace anterior enquanto a adjacência com o PLR continuar ativa; a falha do próprio nó anterior exige remoção normal. Um NP-MP pode preservar o estado diante da falha do enlace ou nó intermediário, desde que sobreviva a relação com o PLR mais distante e não ocorra um dos eventos de término previstos. Se o roteador acumula as duas funções, perder apenas uma das adjacências após a falha de enlace pode não encerrar a proteção. Os períodos de tolerância de reinicialização graciosa devem ser respeitados antes de declarar a adjacência perdida.

A limpeza que não espera o desvio ficar pronto

Remote PathTear resolve o caso inverso: o ponto de junção não deve mais esperar. Uma ordem de gerenciamento chega à entrada para retirar o LSP enquanto o PLR está iniciando o reparo, antes de concluir a sinalização do caminho de proteção. Remover apenas o estado local deixaria o MP aguardando uma operação cancelada.

O PLR envia a mensagem ao endereço Node-ID do MP, com a identidade usada na adjacência de sinalização. Não precisa de um desvio operacional nem da sinalização de proteção concluída. O PLR apaga seu estado; o MP remove os PSB e RSB correspondentes. Na falha do reparo local, o MP também transmite a remoção na direção da saída.

Uma mudança no RRO recebido em Resv pode mostrar que o antigo NP-MP saiu do caminho. O PLR deve então enviar Remote PathTear diretamente a ele. No exemplo normativo, B já concluiu a sinalização de proteção para D quando A manda limpar o antigo ponto C. C encaminha um PathTear normal a D, mas D conserva o estado sustentado pela sinalização já concluída de B. A mensagem remota não ordena a destruição de todos os estados de todos os roteadores seguintes.

A preempção altera a sequência. Se um MP perde a reserva depois de falhar o enlace anterior, mas antes da chegada da sinalização de proteção, deve enviar remoção normal e apagar os estados. O RFC descreve um Path de proteção posterior sendo rejeitado porque o estado necessário não existe mais. É um cenário a testar, não evidência de defeito em um fornecedor atual.

Capacidade anunciada cria uma expectativa concreta

RFC 8370 associa intervalos longos a entrega confiável, confirmações e detecção de falha de adjacência. Os mecanismos de entrega confiável vêm do RFC 2961. RFC 9705 fecha a lacuna do ciclo de vida na proteção por desvio compartilhado. Um equipamento que usa essa proteção não deve anunciar RI-RSVP sem implementar todos os novos procedimentos.

Um B que anuncie suporte sem conseguir enviar as remoções necessárias pode deixar estados antigos por um intervalo longo. Um C que anuncie suporte, mas não entenda CONDITIONS, pode processar a mensagem como normal e eliminar o LSP que deveria preservar. O erro no anúncio se manifesta como retenção excessiva ou como exclusão prematura, conforme sua posição.

O funcionamento misto correto retorna deliberadamente ao intervalo curto. Falta de suporte a jusante reduz o valor de atualização em Path e impede os novos Conditional e Remote PathTear naquele segmento. Falta de suporte a montante altera os valores pertinentes em Resv —e, em alguns casos, em Path— e desativa os novos procedimentos de retenção do MP. A proteção de nó exige também suporte no roteador intermediário. As direções de um mesmo equipamento podem, legitimamente, operar em modos diferentes.

As fontes estabelecem essas regras. Não medem adoção, tempo de recuperação, capacidade disponível ou resultado do cliente. Seu valor está em tornar verificável o motivo de uma reserva continuar existindo ou deixar de existir.

Fontes