Resumo

  • RFC 5376 exigia que o pedido identificasse o AS solicitante para que o PCE receptor aplicasse política local; rejeitar ou alterar prioridade, largura de banda, proteção e classe podia ser uma decisão legítima do dono do recurso.
  • Um identificador opaco de segmento protegia a topologia interna, mas não provava que a sinalização o expandiu corretamente, que recursos foram reservados, que o LSP ficou operacional ou que houve entrega.
  • Como o PCC de origem podia não conhecer os PCEs posteriores, autenticar o par direto não bastava; o AS que calculou o segmento precisava verificar a conformidade entre seu compromisso e o caminho sinalizado.

O não também era uma resposta válida

Automação costuma tratar recusa como erro a ser contornado. Em um ambiente com vários sistemas autônomos, essa reação é perigosa. Cada operador controla recursos, riscos e acordos próprios. RFC 5376 organizou a cooperação sem abolir essa autoridade: o pedido atravessa a fronteira, mas a decisão continua local.

O PCC pode indicar ASes e ASBRs desejados ou excluídos, separar saltos obrigatórios de preferências e expressar largura de banda, proteção, Fast Reroute, disjunção e diversidade. Também deve informar o AS que solicita. O PCE receptor usa essa identidade administrativa, além das condições técnicas, para decidir sob sua política.

O domínio pode negar o pedido. Pode mudar prioridade, capacidade, classe DS-TE ou proteção. Uma restrição formulada para MPLS pode ter de ser traduzida ao entrar em um domínio GMPLS. O protocolo não transforma a vontade do solicitante em posse do recurso remoto.

Por isso, uma rejeição bem formada é evidência. Ela mostra quem decidiu, sob qual política e por quê. Classificá-la automaticamente como indisponibilidade incentiva orquestradores a repetir, contornar ou escalar até encontrar uma porta menos rigorosa. A interface deve diferenciar falha de transporte, impossibilidade técnica e negação autorizada.

Autenticar o PCE remoto tampouco concede jurisdição ilimitada. A credencial responde quem controla uma identidade. A política responde o que essa identidade pode pedir. A decisão responde o que foi aceito naquela ocasião. Misturar os três passos transforma segurança de canal em autorização substantiva que ela nunca ofereceu.

A transformação precisava deixar vestígios

Quando o pedido muda ao cruzar um AS, o registro precisa manter o antes e o depois. Não basta guardar o valor final da prioridade ou da largura de banda. É necessário saber o valor original, a autoridade que reinterpretou, a regra aplicada e se uma condição obrigatória permaneceu obrigatória.

Essa proveniência é especialmente importante entre tecnologias. Um parâmetro com sentido conhecido em MPLS pode ganhar outra realização em GMPLS. A compatibilidade sintática não garante equivalência operacional. Se o caminho falhar depois, sem o histórico de tradução ninguém saberá se o cálculo desrespeitou o pedido ou se o pedido foi legitimamente adaptado.

O mesmo cuidado vale para o custo. RFC 5376 admite custo acumulado no caminho inter-AS, mas deixa fora de escopo a normalização entre domínios. Um total pode somar escalas diferentes, preferências administrativas ou objetivos comerciais. O número foi transportado; a unidade comum não foi criada.

Chamar o menor total de ótimo exige uma política adicional: função objetivo, métricas comparáveis, normalização, domínios cobertos e restrições. Métodos por domínio podem encontrar um caminho aceitável sem garantir ótimo global. Preservar contribuições individuais permite revisar a decisão; guardar apenas o total congela uma certeza que nunca existiu.

A chave opaca mantinha a topologia em casa

Operadores têm razões de segurança e negócio para não publicar links, capacidades e desenho interno. RFC 5376 permitiu que uma resposta mostrasse ASes e ASBRs necessários à composição, mas substituísse saltos internos por um identificador de segmento. O solicitante recebe uma referência útil sem receber o mapa.

Essa abstração também se aplica à cadeia de cálculo. Um PCE inter-AS pode pedir um segmento a outro PCE inter-AS ou a um PCE dentro do domínio. O PCC de origem talvez não conheça os participantes posteriores. A presença de um PCE pode ser confidencial fora da relação com seu par direto.

O identificador opaco representa um resultado calculado em certo momento, com determinado estado e política. Ele não demonstra que a sinalização posterior o utilizou. Não demonstra que a expansão correspondeu ao resultado, que RSVP-TE reservou recursos, que o LSP entrou em operação ou que um pacote chegou à aplicação.

RFC 5376 era um documento Informativo de requisitos, publicado em novembro de 2008. A expansão em sinalização ficou fora de seu escopo. RFC 5440 especificou PCEP e RFC 5520 tratou de path keys; arquiteturas hierárquicas, extensões stateful e TLS vieram depois. Nenhuma extensão elimina a separação entre resposta de cálculo e fato operacional.

Quem escondia também precisava conferir

A confidencialidade cria uma assimetria inevitável. O solicitante não pode comparar a expansão com os saltos internos porque não os conhece. Logo, a verificação deve ocorrer no AS que tem os dois lados do fato: o segmento originalmente calculado e o caminho que a sinalização tentou instalar.

RFC 5376 pede um mecanismo, refletido na sinalização correspondente, para que um AS verifique que o caminho sinalizado está conforme o segmento do seu PCE local. A palavra importante é conformidade. Validar que a chave existe ou chegou por uma sessão protegida não diz que ela foi expandida para o compromisso correto.

Imagine a chave K criada para sair por um ASBR específico, com proteção e capacidade definidas. Entre o cálculo e a sinalização, uma política muda ou um cache antigo é usado. A expansão pode produzir outro trajeto sem alterar a aparência da chave para o exterior. O AS proprietário precisa vincular K ao contexto, às versões de topologia e política, à expansão observada e a um resultado verificável.

Isso não obriga a revelar o mapa. O domínio pode declarar que a expansão correspondeu ao compromisso e conservar internamente os detalhes necessários para auditoria. A prestação de contas permanece onde há conhecimento; a divulgação continua mínima.

Cooperação não era confiança automática

Pares PCE devem autenticar identidades, validar dados e proteger a troca por criptografia. A distribuição de chaves entre ASes deve respeitar a disciplina de gerenciamento descrita em RFC 4107. Essas medidas defendem a comunicação direta, não criam por si só uma cadeia universal.

O PCE A pode confiar no PCE B, que consulta C. O PCC na origem pode autenticar apenas A. Uma cadeia de confiança é recomendável, porém pode não estar disponível em todos os casos. O expediente precisa dizer qual par foi autenticado, qual contribuição veio de um domínio oculto e qual autoridade verificou o segmento.

Objetos de política podem ser opacos ao protocolo que os transporta. Se a origem, integridade ou autorização do conteúdo exigir controles adicionais, o componente de política que entende o objeto precisa aplicá-los. Um envelope cifrado protege bytes, não julga o mandato que eles expressam.

PCEP protegido por TLS melhora identidade e confidencialidade de transporte. PCE stateful amplia a visão do estado. PCE hierárquico melhora coordenação. Nenhum desses recursos torna todo pedido autorizado, toda métrica comparável ou toda computação uma entrega concluída.

Um fluxo com recibos independentes

Uma implementação governável deveria guardar pelo menos seis registros:

  1. pedido: endpoints, AS solicitante, AS/ASBR obrigatórios ou excluídos, capacidade, proteção e diversidade;
  2. política: autoridade decisora, valores aceitos, modificações, traduções e motivo da recusa;
  3. cálculo: versão do estado, PCEs divulgáveis, saltos explícitos ou referências opacas;
  4. conformidade: comprovação do AS proprietário de que a sinalização expandiu o segmento calculado;
  5. estabelecimento: resultado da sinalização, reserva, rótulos e estado operacional do LSP;
  6. resultado: observação de encaminhamento, qualidade, recepção e confirmação da aplicação.

Uma resposta PCE de sucesso não preenche automaticamente os três últimos. Se o estabelecimento falhar, o cálculo pode continuar correto. Se o tráfego parar depois, a reserva pode ter sido válida. Se a política alterou um parâmetro, o caminho realizado já não deve ser descrito como reprodução literal do pedido.

Os recibos também tornam mudanças reversíveis. Um domínio pode retirar uma chave, recalcular após falha, negar uma nova prioridade ou rotacionar credenciais. A história mantém decisões antigas com seu tempo e contexto, em vez de reescrever tudo como um único sucesso ou fracasso.

O alcance seguro da conclusão

Os documentos oficiais sustentam requisitos e evolução do protocolo. Eles não demonstram implantação atual de um provedor, acordo comercial, incidente, desempenho ou entrega. Também não autorizam inferir os saltos escondidos a partir da chave.

A conclusão durável é institucional. A automação inter-AS só funciona de modo responsável quando cada domínio conserva poder sobre recursos e produz evidência limitada do que conhece. O solicitante expressa intenção; o receptor aplica política; o PCE calcula; a sinalização tenta estabelecer; o proprietário verifica a expansão; a operação observa o resultado.

Esse desenho evita duas escolhas ruins: obrigar todos a expor a topologia ou aceitar uma caixa-preta sem controle. Uma referência mínima, associada à decisão local e a uma verificação posterior, permite cooperação sem autoridade fictícia.