Resumo

  • A RFC 9504 distingue capacidade, sincronização de estado, atualização e pedido de iniciação; nenhum desses registros, isoladamente, é prova de resultado operacional.
  • A delegação dá ao PCE uma permissão delimitada sobre atributos de LSP e continua subordinada ao PCC, à política local e à possibilidade de retirada.

Em uma operação de rede, uma palavra no painel pode parecer mais definitiva do que é. “Delegado” sugere que alguém entregou a chave da sala de operações. Só que, no vocabulário de PCEP, a chave não mudou de dono. Existe uma relação específica entre PCC, PCE e atributos de um ou mais LSPs, com condições explícitas e saída possível.

A RFC 9504 leva extensões de PCE com estado para redes GMPLS. Ela organiza a conversa entre quem calcula caminhos e quem mantém o lado cliente do protocolo: capacidades, relatórios de estado, atualizações e iniciação. Essa conversa pode ser essencial para coordenar engenharia de tráfego. Mas coordenação não é a mesma coisa que autoridade institucional, e uma solicitação enviada não é uma ação consumada.

A primeira distinção está na capacidade. Para usar funções GMPLS de reporte, atualização ou iniciação, PCC e PCE precisam suportá-las e permiti-las. O acordo descreve que os dois lados podem falar sobre uma função. Não diz que o operador autorizou uma mudança naquela janela, que o recurso existe, que um equipamento aceitou a configuração ou que o plano de encaminhamento já foi alterado. O registro IANA de números PCEP cumpre uma função ainda mais estreita: mantém códigos identificáveis; não atesta operação em campo.

A segunda distinção é a propriedade do estado. Na RFC 8231, o PCE com estado precisa conhecer o estado de LSP no PCC antes de calcular ou atualizar atributos. Um State Report relata; um Update Request pede. A delegação permite ao PCE atualizar atributos de LSPs determinados enquanto vigora. Ao mesmo tempo, o PCC permanece proprietário do estado, aplica política local e pode retirar a delegação. A frase aparentemente pequena — “enquanto vigora” — impede que uma permissão protocolar seja confundida com uma transferência de responsabilidade pela rede.

Isso vale também para PCInitiate. A RFC 8281 define o LSP iniciado por PCE como aquele instanciado em resultado de uma requisição do PCE e descreve a mensagem como gatilho para o nó final configurar o LSP. Um gatilho abre uma sequência; ele não comprova cada etapa dela. Aceitação do nó, reserva de recurso, configuração de cross-connect, caminho instalado e tráfego efetivo precisam de registros próprios. Uma leitura cuidadosa do caminho pretendido e do caminho real em relatórios de RFC 9504 não elimina essa necessidade: ela apenas torna possível investigar melhor a diferença.

O teste operacional é simples. Se uma afirmação não puder dizer se fala de capacidade, de estado informado, de permissão delegada, de pedido, de aceitação local, de ação de equipamento ou de resultado observado, ela é ampla demais para uma decisão importante. Cada camada tem valor probatório distinto. Uma pode apontar para a próxima sem se apropriar dela.

Essa separação coincide com a ideia de Heng Lu de uma especificação inicial mínima: a camada comum deve dizer o bastante para interoperar, deixando adoção e decisão de consequência onde o risco é suportado. O código em execução é uma referência útil para saber se um mecanismo funciona. Não é uma licença para declarar que a responsabilidade local deixou de existir.

Para uma equipe que usa PCE, a pergunta prática é: que atributo foi delegado, por qual PCC, sob qual política, e qual evidência nos leva do pedido até o efeito? A resposta não reduz automação. Ela impede que a automação seja usada para substituir prestação de contas.

Fontes