Resumo

  • A RFC 3423 distinguiu o ACK do transporte, útil para perda de pacotes e servidor sem resposta, do DATA ACK do CRANE, emitido depois de processar corretamente os registros em sequência e colocar a informação contábil em armazenamento persistente.
  • A confirmação persistente não encerrava a investigação: DSN, troca de servidor, bit Duplicate, configuração do template, segurança do canal e reconciliação financeira continuavam sendo recibos diferentes.

Um sucesso antes do compromisso

O equipamento envia um registro de uso. O transporte confiável confirma os bytes. O processo remoto ainda precisa interpretar, processar e gravar. Se ele cair antes dessa última etapa, a rede cumpriu sua promessa e o sistema contábil não cumpriu a dele.

A RFC 3423, de novembro de 2002, transformou esse intervalo no centro do Common Reliable Accounting for Network Element, da XACCT Technologies. O texto simples, a página informativa, o registro no IETF, o histórico, as referências e a busca de erratas preservam uma proposta Informational. Ela não era Internet Standard e não mede implantação atual.

CRANE queria exportar grandes volumes de dados de elementos de rede para mediação, BSS e OSS. Sua disciplina mais interessante foi impedir que a palavra confiável terminasse cedo demais.

O ACK do transporte não escrevia no armazenamento

O protocolo precisava de transporte confiável, orientado a conexão e em ordem. TCP servia; o documento preferia o SCTP histórico da RFC 2960 por recursos como orientação a mensagens e detecção rápida de falha. Isso é uma escolha do documento, não evidência de adoção.

ACKs do transporte detectavam pacotes perdidos e receptores sem resposta. O ACK do CRANE vinha depois que a mensagem fora processada e os dados contábeis colocados em armazenamento persistente. Uma camada respondia “os bytes chegaram”; outra, “a aplicação incorporou este trecho de forma durável”.

A RFC 2975 já tratava armazenamento não volátil e eliminação de duplicatas como parte da gestão contábil. O CRANE expôs essa distância no próprio fluxo. A saúde da conexão deixou de ser um substituto aceitável para a saúde do registro.

DSN marcava uma fronteira sem buracos

Cada DATA levava um Data Sequence Number. No início ou após transição, o cliente ativava o bit S para sincronizar o primeiro DSN. Cada novo registro aumentava o número em um. O servidor aceitava a sequência correta e descartava uma chegada fora de ordem.

DATA ACK levava o último DSN processado corretamente dentro da sequência contínua. Ver 3123 sem 3122 não autorizava confirmar 3123. O receptor repetia a fronteira atual e provocava a retransmissão do que faltava.

Essa fronteira era forte para sua pergunta, mas não provava a pergunta seguinte. Não dizia se o registro pertencia ao assinante certo, se a tarifa estava correta, se uma fatura fora emitida ou se o armazenamento sobreviveria a todo desastre posterior.

Failover distribuía a história

Uma sessão podia ter servidores redundantes com prioridades. O cliente enviava ao operacional de maior prioridade que percebia. Sem nenhum, enfileirava localmente até a recuperação ou o esgotamento do espaço; o segundo caso pedia alarme.

A mudança podia nascer de porta sem resposta, bytes não confirmados acima de um limite durante certo tempo, STOP do servidor ativo ou retorno de um servidor preferido. O mecanismo era especificado; a política exata de transição permanecia da implementação.

O exemplo da RFC divide a sequência: servidor 1 recebe 3042–3095; servidor 2, 3096–3122; servidor 1 volta em 3123. Nenhum receptor isolado possui tudo. A obrigação de completar pertence ao emissor e ao sistema de mediação.

Reenvios podiam duplicar. Ao mandar novamente para outro servidor, o cliente ativava o bit Duplicate; o destino final usava DSN para remover cópias. O bit não era um comprovante de duplicata nem de deduplicação. Era uma advertência para uma etapa que ainda precisava ocorrer.

Persistência não corrigia um template errado

Para evitar descritores em cada registro, CRANE negociava templates. Eles ordenavam chaves, tipos e significados; chaves podiam ficar ativas ou inativas. Todos os servidores da sessão deveriam manter o mesmo conjunto e estado.

Cada registro carregava Template ID e Configuration ID. Um receptor podia manter histórico curto para configurações antigas. A ordem de transporte deveria evitar uma versão futura chegando cedo, e uma mudança deveria esperar a confirmação dos DATA da versão anterior.

Cada servidor tinha uma oportunidade de propor alterações. O cliente escolhia o resultado e distribuía FINAL TMPL DATA; depois disso, os receptores aceitavam sem nova edição. A assimetria encerrava loops e atribuía ao cliente a decisão final.

Logo, bytes podem estar intactos no disco e ainda assim ter interpretação errada. Armazenamento, esquema e significado exigem contexto conjunto.

Protocolos vizinhos, garantias não intercambiáveis

A introdução comparava RADIUS e Diameter. A RFC 2865 define acesso RADIUS e a RFC 2866, accounting. Diameter apareceu na RFC 3588 e foi atualizado pela RFC 6733. A RFC 3334 trata requisitos para accounting baseado em políticas.

IPFIX oferece contexto posterior em seu protocolo, modelo de informação e orientação de implementação. O paralelo mostra problemas recorrentes, não descendência implantada, compatibilidade ou equivalência de recibos.

Os termos normativos seguem a RFC 2119. MUST descreve a obrigação do texto, não a telemetria de um binário.

Segurança continuava fora da confirmação

O próprio documento dizia que CRANE não fornecia confidencialidade e integridade fortes. Provisionar endereços de clientes e servidores organizava a confiança, mas sem defesa adicional deixava risco de spoofing. IPsec ou TLS eram recomendados conforme o ambiente.

DATA ACK, portanto, não autenticava automaticamente o par nem provava integridade ponta a ponta. Canal, identidade, autorização, template, persistência e resultado de negócio continuavam separados.

Fontes e limites

A leitura também usa Heng Lu sobre camadas da realidade e código em execução como fonte primária. Especificação, implementação, configuração, observação e estado de negócio não são cópias da mesma coisa.

As fontes sustentam a história e a semântica. Não sustentam uso atual, desempenho medido, incidente identificado, produto sobrevivente nem conformidade de uma instalação real.