RFC 3084: entregar a política não provava estado comum

Resumo

Na RFC 3084, todas as decisões dentro de uma mensagem DEC de COPS-PR formavam uma só transação. Ou o PEP aplicava o conjunto inteiro, ou informava falha e voltava à última transação bem-sucedida.
O RPT de sucesso não encerrava o problema. Durante a desconexão, o equipamento podia continuar aplicando política em cache; ao reconectar, era preciso sincronizar os Request-States ou assumir que as duas memórias ainda coincidiam.

A política passou a existir dentro de outro sistema

Um PDP envia a remoção de um filtro antigo e a instalação do substituto na mesma DEC. O TCP entrega os bytes. O PEP responde Success. O servidor agora possui um recibo de execução, não apenas a confirmação de que tentou transmitir.

Ainda assim, o recibo termina na fronteira do dispositivo. O PEP precisa converter instâncias da PIB em filas, classificadores e ações locais. Um RPT não mostra a trajetória de um pacote nem comprova que a aplicação recebeu o nível de serviço esperado. Ele responde a uma pergunta importante, mas limitada: a transação foi aceita pelo ponto de aplicação?

Publicada em março de 2001, a RFC 3084 definiu o COPS-PR, uso do Common Open Policy Service para provisionamento. Um Policy Decision Point fornecia dados a um Policy Enforcement Point. A Policy Information Base organizava classes e instâncias; PRI era a instância e PRID, seu identificador. O protocolo carregava modelos de áreas como QoS e segurança sem impor uma única semântica de política.

Essa é uma fronteira diferente daquela já tratada no artigo sobre a RFC 3060. O PCIM separava o esquema comum do algoritmo que o interpretava. O COPS-PR tratava do estágio seguinte: como instalar uma decisão, receber seu resultado, manter estado durante a falha e reconciliar duas cópias depois.

A transação protegia a substituição incompleta

Uma DEC podia reunir várias decisões. As remoções vinham antes das instalações para resolver precedência, não para criar uma promessa de intervalo temporal. A mensagem inteira devia ter um único resultado. Se uma parte não pudesse ser instalada, o PEP enviava Failure e restaurava o estado deixado pela última DEC correta.

Isso impedia que a regra antiga desaparecesse sem que a nova entrasse. Cada DEC exigia um RPT solicitado, inclusive uma decisão nula. A cadeia distinguia intenção no PDP, aceitação no PEP e, depois, os efeitos que ainda precisavam ser observados.

A própria RFC marcou o limite do rollback. Uma falha solicitada e imediata tinha um ponto anterior bem definido. Mas uma configuração antes aceita podia quebrar mais tarde e gerar um relatório não solicitado. Nesse cenário assíncrono, o texto dizia que o estado correto podia ter se tornado ambíguo. O PEP conseguia informar o problema, sem necessariamente conseguir reconstruir o passado.

Compatibilidade não significava igualdade

As PIBs podiam receber novas classes. Um PDP mais novo que enviasse uma PRC desconhecida a um PEP antigo provocava erro e retorno ao estado bom anterior. No sentido oposto, um PEP mais novo conectado a um PDP antigo apenas não recebia instâncias da classe nova. Classes descontinuadas tinham regras próprias de omissão.

Esse comportamento tornava o desencontro administrável, mas não demonstrava paridade. Um sucesso comprovava o conjunto efetivamente processado, não que ambos conheciam as mesmas extensões, tinham as mesmas capacidades ou instalavam mecanismos locais equivalentes.

O COPS-PR também reduzia escritores concorrentes. Para uma área identificada por Client-Type, uma conexão deixava um único servidor responsável pela atualização. Enquanto o PEP estivesse conectado, a configuração ficava efetivamente bloqueada até contra alterações do console local. A exclusividade simplificava autoridade e transformava a identidade do PDP e seu estado persistente em dependências críticas.

Na falta do servidor, o cache continuava governando

Ao perder comunicação, o PEP tentava o último PDP e depois um secundário configurado. Enquanto isso, o Request-State ativo continuava tomando decisões. Ao reconectar, LastPDPAddr identificava a origem das decisões ainda armazenadas. O PDP podia pedir sincronização com SSQ.

Nesse processo, o PEP reenviava as REQ de todos os Request-States conhecidos. O PDP emitia exclusões de PRIDs ou prefixos para remover resíduos e chegar a um estado conhecido. Se não solicitasse sincronização, o cliente podia presumir que o servidor o reconhecia e considerava correto o cache atual. Era uma regra operacional, não uma medição independente de igualdade.

Mudanças locais ocorridas durante a interrupção ainda precisavam ser relatadas. Se o contato não voltasse dentro de um prazo administrativo, o PEP apagava os Request-States instalados, e o PDP expirava seus registros correspondentes. Os dois lados continham a autoridade órfã, mas cada um executava seu próprio temporizador.

O ecossistema avançou com SPPI e PIBs para QoS, framework e feedback de uso. Em 2016, o IETF moveu a RFC 3084 e documentos relacionados para Historic, citando implantação limitada e a concentração do gerenciamento de configuração em NETCONF e YANG. Essa decisão registra uma mudança de direção; não autoriza afirmar que nenhuma implementação existiu ou que todas deixaram de operar.

A contribuição histórica da RFC 3084 é mostrar que política distribuída precisa de uma cadeia de provas. A intenção do PDP, a DEC atômica, o RPT, o cache, a ressincronização, o mecanismo local e o resultado do tráfego são camadas diferentes. Entrega confiável move a regra; reconciliação e observação revelam qual regra o equipamento realmente manteve.

O servidor enviou as regras. A reconexão ainda precisava conciliar o que o equipamento guardou: RFC 3084

Por que isso importa

Resumo

A política passou a existir dentro de outro sistema

A transação protegia a substituição incompleta

Compatibilidade não significava igualdade

Na falta do servidor, o cache continuava governando

Fontes

Contexto aprofundado do perfil

Strategic Circle

Leadership Alliance

Briefing do Strategic Circle

Briefing da Leadership Alliance