Resumo

  • O RFC 5151 cobre LSPs RSVP-TE que atravessam ASes, áreas IGP ou overlays GMPLS.
  • O ingress restringe o método, enquanto cada borda aplica política local a sinalização contígua, aninhada ou costurada.
  • A borda expande loose hops e pode escolher a saída sem exportar todos os dados de cálculo.
  • Por confidencialidade, um PathErr de nó específico pode virar uma falha geral do domínio.
  • A borda não pode suprimir PathErr, exceto enquanto tenta um crankback permitido.
  • Se a tentativa posterior funcionar, o erro retido é descartado; se todas falharem, segue para o ingress.
  • Hops internos do RRO podem virar um identificador de domínio ou sumir, mas a própria borda deve aparecer.
  • A sinalização continua funcionando após o filtro, embora o diagnóstico de gestão possa ficar inoperante.
  • Fast Reroute pode perder eficiência quando faltam no RRO o label e o merge point necessários.
  • Trocar o destinatário de Notify acelera ação local, mas adiciona processamento e encaminhamento em cada domínio.
  • O bit 4 comprova a escolha do método contíguo, não visibilidade, diversidade, recuperação ou entrega.
  • A garantia exige recibos separados de restrição, política, exposição, tentativas, caminho oculto, proteção e tráfego.

O bit 4 fecha uma escolha e deixa outras abertas

O ingress usa o bit 4 Contiguous LSP no TLV Attributes Flags quando exige uma única sessão RSVP e um LSP ID ao longo do caminho. Uma borda que recebe o bit marcado não pode fazer nesting ou stitching. Com o bit limpo, a política local pode escolher essas alternativas. Nós de trânsito não podem alterar a solicitação.

Quem reconhece objeto, TLV e bit, mas não suporta operação contígua, precisa devolver Routing Problem valor 28. Uma borda capaz ou um nó que expande loose hop deve sinalizar de forma contígua e, se houver RRO, marcar esse comportamento no subobjeto Attributes. Quem não reconhece TLV ou bit encaminha o objeto sem modificá-lo.

Esse é um recibo preciso de construção. Não determina quais hops internos serão publicados, quão específica será uma falha, se um Notify chegará ao destinatário original ou se o plano de dados entregou o serviço.

Cada domínio ainda conserva autoridade

Sem a exigência de continuidade, um domínio pode usar H-LSP para nesting ou segmentos para stitching. Um único LSP e2e pode combinar métodos. O ingress define limites; as bordas escolhem dentro deles conforme capacidade, configuração e política.

Um domínio de trânsito pode preferir stitching para reotimizar sua parte sem depender do ingress. O ingress pode preferir o modo contíguo para controlar o caminho e o momento da mudança. Se as políticas não se encontram, a borda rejeita e o ingress evita o domínio, relaxa a exigência ou deixa de prestar o serviço.

A topologia de autoridade permanece distribuída mesmo quando a sinalização é contígua. Para governar o resultado, é preciso saber qual domínio tomou cada decisão e qual evidência reteve.

ERO termina onde começa o cálculo local

O Explicit Route Object que chega a uma borda já reflete técnica de cálculo, visibilidade TE e alterações anteriores. A borda pode rejeitar um ERO que nomeia equipamentos internos, normalmente com Inter-domain explicit route rejected; por segurança, pode descartar o Path ou devolver informação diferente.

Um próximo hop loose, IP ou AS, é expandido usando cálculo local. Sem subobjeto após a borda, o destino da RSVP Session vira o próximo hop loose. Se o ERO identifica um TE link criado por H-LSP ou segmento anunciado, operação contígua não é permitida; capacidade, parâmetros e policy escolhem nesting ou stitching.

O ERO final mostra a rota que as autoridades concordaram em sinalizar. Não mostra todos os candidatos, restrições privadas ou riscos que influenciaram a seleção.

O PathErr pode conservar o evento e reduzir a causa

Falha de setup produz PathErr no sentido do ingress. Cada borda o vê. Se confidencialidade for requisito específico, uma borda pode trocar a falha de um nó por erro geral do domínio. Nós comuns não devem modificar a mensagem, e bordas não devem fazê-lo sem necessidade.

Ela também não pode simplesmente engolir o erro. Pode retê-lo durante crankback, tentando rota interna ou domínio downstream alternativo. Sucesso posterior obriga descartar o PathErr retido; fracasso de todas as tentativas obriga encaminhá-lo, possivelmente com detalhes agregados.

Ausência de erro é inconclusiva sem o ledger de tentativas. O novo LSP e a observação de tráfego comprovam sucesso. O silêncio apenas mostra que o ingress não recebeu aquela versão do erro.

Um RRO correto pode ser pobre para investigar

Por política de confidencialidade, a borda pode substituir vários hops internos por um número de AS ou removê-los, deixando as bordas. Ela não pode esconder a si mesma e precisa entrar no RRO.

O RFC afirma que esse filtro não prejudica o funcionamento da sinalização. Também afirma que a perda pode tornar o diagnóstico inoperante ou exigir coordenação entre administradores. O RRO continua correto em seu escopo público, mas não representa saúde, risco ou percurso do interior.

Procedimentos automáticos também sentem a perda. Fast Reroute usa o RRO para determinar labels e downstream merge point. Manter o LSP atual não é o mesmo que manter informação suficiente para protegê-lo com eficiência.

Diversidade precisa de um caminho de referência

Bypass tunnels, detour LSPs e recuperação de segmento passam pelas mesmas policies e regras de ERO. Quando o backup contém loose hops, o nó que os expande precisa conhecer o caminho protegido entre PLR e MP para manter separação.

RRO, DETOUR e route exclusion fornecem partes desse conhecimento; PCEs coordenados são outra opção. Um domínio pode manter seu mapa privado e ainda produzir uma prova verificável de exclusão. O que não funciona é declarar diversidade sem qualquer ator capaz de comparar o risco comum.

O recibo nomeia conjunto de risco, versão do working path, exclusões, backup escolhido e resultado de switchover. Inventário de tunnel não é resultado de proteção.

Notify cria uma fila entre autoridades

Notify pode ser enviado diretamente. Uma borda que pretende executar proteção local é incentivada a substituir Notify Request pelo próprio endereço. Mensagens inicialmente destinadas ao ingress passam a depender de análise, filtragem e encaminhamento em cada fronteira.

A reação local pode ser mais rápida. O custo de processamento cresce linearmente com o número de domínios, e o conteúdo pode ser modificado para preservar segurança. Recebimento na borda prova apenas aquele trecho.

Uma cadeia defensável registra destinatário original, substituições, versão do conteúdo e confirmação de cada repasse. Sem isso, o primeiro alerta vira indevidamente uma afirmação e2e.

Reotimização local preserva limites e acumula efeitos

No modo contíguo, make-before-break começa no ingress. Em nesting ou stitching, um domínio pode reotimizar H-LSP ou segmento se mantiver suas bordas. A operação curta reduz exposição e preserva autonomia.

Mas um domínio pode aceitar sua qualidade local enquanto o head end observa o efeito cumulativo. O ingress pede mudança global, e o trânsito pode ignorar. A ação por domínio não escolhe novas bordas; a ação e2e pode.

Por isso o log deve conectar pedido, proprietário, decisão, caminho antes/depois e medida de tráfego. Uma mudança de controle concluída não garante melhoria percebida.

Confiança habilita sinalização, não transparência total

Administradores vizinhos precisam considerar adequada a relação de confiança antes de habilitar RSVP-TE interdomínio. Sem ela, devem evitar deployment e desabilitar a função nas interfaces. Chaves, filtros de contrato, rate limit e processamento outbound complementam o controle.

Essas medidas defendem o plano de controle e reduzem exposição. Um vizinho autenticado não comprova que a causa interna foi revelada, o backup evita o mesmo risco, a notificação chegou intacta ou o tráfego se recuperou.

O contrato deve definir evidência mínima compartilhada, retenção privada, identificadores de correlação e escalada executável sem exigir publicação de toda topologia.

Fontes

  1. RFC 5151, HTML
  2. RFC 5151, texto
  3. Registro no RFC Editor
  4. Registro no IETF Datatracker
  5. Histórico do RFC 5151
  6. Referências do RFC 5151
  7. Errata do RFC 5151
  8. RFC 3209
  9. RFC 3473
  10. RFC 4206
  11. RFC 4420
  12. RFC 5150
  13. RFC 4726
  14. RFC 4208
  15. RFC 4920
  16. RFC 4090
  17. RFC 4873
  18. RFC 4874
  19. RFC 4655
  20. RFC 4216
  21. RFC 4105
  22. RFC 2747
  23. RFC 5152
  24. Parâmetros RSVP da IANA
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy