Resumo

  • RFC 5152 calcula trechos de um LSP TE entre domínios quando o head end não dispõe da rota completa.
  • Cada borda usa TED, reachability, capacidade e policy locais, podendo escolher o egress de seu domínio.
  • O ERO combina strict e loose hops, misturando controle antecipado com expansão delegada durante signaling.
  • Saídas podem ser configuradas ou descobertas via IGP, BGP ou policy; uma saída reachable não é recibo de ótimo global.
  • Falha downstream envia PathErr; crankback pode tentar outro egress, e o head end pode mudar sequência, repetir ou relaxar constraints.
  • Cada ação responde a uma pergunta diferente e precisa preservar o objetivo efetivamente testado.
  • O RFC declara que o método per-domain não garante o caminho interdomínio ótimo.
  • No trapping problem, a primeira rota viável pode impedir a segunda embora outra dupla diversificada exista.
  • Logo, “não encontrado” depende da primeira rota, ordem, visibilidade, exclusões e algoritmo.
  • Reotimização pode melhorar S-LSPs ou H-LSPs locais mantendo a mesma sequência ruim de bordas.
  • O provedor pode selecionar outra técnica por LSP, mas PCE, retry ou crankback não são garantias universais.
  • O serviço deve conservar recibos de objetivo, método, grafo, escolhas, recursos, falhas, alterações e entrega observada.

A escolha do método começa na promessa comercial

Há pelo menos três produtos diferentes escondidos sob “calcular uma rota”. O primeiro pede qualquer LSP que satisfaça constraints. O segundo pede um caminho ótimo segundo uma métrica. O terceiro pede um conjunto cujos membros não compartilhem um risco definido.

Per-domain computation é uma técnica concreta para o primeiro cenário e pode atender outros em topologias e condições específicas. O RFC, porém, afirma que não garante o ótimo interdomínio e pode não encontrar duas rotas diversas por causa de trapping.

Se a contratação não nomeia qual problema está sendo resolvido, o método mais simples vira default e seu primeiro sucesso passa a representar promessas que nunca foram calculadas. A técnica deve ser escolhida por classe de serviço antes da reserva, não justificada depois pelo LSP que já existe.

A rota nasce em decisões que ficam sobre ela

O head end usa per-domain computation quando não vê ou não sinaliza todo o trajeto. O Path leva destination e informações até a próxima fronteira; pode incluir outros boundary LSRs ou identificadores de domínio.

Cada nó responsável pelo cálculo permanece no LSP resultante. O ABR/ASBR expande a parte local, talvez selecione o egress, e passa adiante uma solicitação já condicionada. Se o AS contém áreas ou sub-ASes, o modelo se repete.

Isso reduz exposição de topologia e preserva autoridade operacional. Também faz da ordem um dado de negócio: a saída escolhida cedo define que resources e combinações restarão aos domínios seguintes.

Strict e loose hops dividem o controle

O ERO pode descrever o caminho strict completo, apenas o trecho strict no source domain, a lista de fronteiras ou somente a fronteira atual e o destino. Elementos strict e loose podem coexistir.

Um strict node segue RSVP-TE comum. Um loose hop ou abstract node que reúne vários LSRs delega expansão à borda. A solução permite controlar onde há visibilidade e confiar cálculo ao dono do restante.

O ERO final prova a descrição que sobreviveu. Não mostra candidates, ordem de comparação, critérios de poda nem se o algoritmo otimizou uma rota ou a relação entre duas. Esses dados precisam de um ledger de cálculo separado.

Reachability abre a porta; não reserva o próximo domínio

Se o next hop não está na TED, a borda confirma que ele fica fora do domínio, verifica as condições de packet switching e in-band control e procura reachability IP. Falha gera Routing Problem PathErr.

IGP, BGP ou policy routing podem descobrir a próxima fronteira. Na ausência disso, o egress precisa estar configurado ou ser fornecido por outro esquema. Sem ele, o cálculo interdomínio falha.

Esse mecanismo responde onde encaminhar o pedido. Não prova disponibilidade TE downstream, melhor escolha de egress ou preservação de uma dupla. Dashboard e contrato devem manter esses receipts separados.

Uma primeira vitória pode bloquear o produto contratado

No exemplo A-B-C-D, a abordagem serial escolhe esse caminho primeiro. Depois não encontra uma rota diversa dele. A topologia, entretanto, contém A-C-D e A-B-D como dupla.

O primeiro LSP pode ser totalmente válido. Esse é o núcleo do alerta: sucesso local e protocolar não impede erro de formulação global. A capacidade existe, mas foi combinada de um modo que a torna indisponível para o segundo objetivo.

Por isso uma resposta negativa deve incluir first-path hash, risk set, topology version, visibility boundary e algorithm. Sem esses qualifiers, a frase “não existe backup” apaga que o próprio primeiro caminho criou a restrição.

Crankback, retry e relaxation não são sinônimos

Quando o domínio seguinte não satisfaz constraints, envia PathErr. Crankback pode devolver a decisão à fronteira anterior e tentar outro egress. Sem ele, o erro segue ao head end.

O head end pode selecionar outra sequência loose, repetir a mesma se suspeitar de IGP-TE state antigo, ou relaxar constraints. Trocar egress explora branch; repetir testa freshness; relaxar compra outro serviço.

O registro precisa congelar a entrada de cada attempt. Se o último ficou verde depois de abandonar uma exclusão ou reduzir banda, ele não substitui o receipt de que a solicitação original falhou.

Diversidade é propriedade da dupla

Uma rota não é “diversa” sozinha. Ela é diversa de outra em relação a links, nodes, facilities, SRLGs ou domínios nomeados. O cálculo precisa possuir essa relação antes de fixar a primeira.

O RFC permite escolher método per LSP e aponta técnicas PCE quando optimality ou conjuntos diversificados importam. A palavra PCE não basta: é preciso saber quais grafos, constraints e risks estavam visíveis e atuais.

Uma especificação mínima honesta diz qual problema, dados e algoritmo produziram o resultado. Uma decisão futura localizada pode escolher técnica diferente sem reinterpretar o receipt antigo.

Melhorar segmentos não recompõe automaticamente o conjunto

Contiguous LSP usa head-end controlled make-before-break. Stitched ou nested permite que cada domínio reotimize seu S-LSP/H-LSP, com frequência e critérios próprios, às vezes de modo transparente.

Se o operador não deseja transparência, RFC 4736 pode exigir que eventos locais sejam reportados ao head end. Ainda assim, loose boundary LSRs podem continuar iguais.

Todos os segmentos podem melhorar dentro da moldura existente e a sequência de fronteiras continuar subótima. O receipt de reoptimization deve dizer se mudou interior, egress, domain sequence ou a dupla inteira.

Confidencialidade requer conclusão proporcional

O método não aumenta a topologia compartilhada entre ASes. Cada domínio calcula com seu grafo privado. A autonomia é preservada sem inventar uma autoridade central sobre todos os detalhes.

Boundary computation também precisa de defesa: policy contra ERO expansion indevida, contratos de bandwidth/priority, rate limit, outbound filtering e RSVP authentication. FRR em bordas pode exigir sincronização de chaves com PLR e MP.

Esses controles tornam o trabalho autorizado e íntegro. Não demonstram busca exaustiva, diversidade, recovery, nem entrega no plano de dados. Cada reality layer conserva seu próprio receipt.

Fontes

  1. RFC 5152, HTML
  2. RFC 5152, texto
  3. Registro no RFC Editor
  4. Registro no IETF Datatracker
  5. Histórico do RFC 5152
  6. Referências do RFC 5152
  7. Errata do RFC 5152
  8. RFC 3209
  9. RFC 3473
  10. RFC 5151
  11. RFC 5150
  12. RFC 4920
  13. RFC 4655
  14. RFC 4726
  15. RFC 4105
  16. RFC 4216
  17. RFC 4736
  18. RFC 2747
  19. RFC 3097
  20. RFC 3630
  21. RFC 4203
  22. RFC 4205
  23. RFC 6805
  24. RFC 8694
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy