Resumo

  • O FAS podia permitir, rejeitar, redirecionar ou impor políticas; o switch continuava sendo o ponto onde a conectividade surgia.
  • As mensagens LFAP eram comprovantes de etapas separadas, e nenhuma delas isoladamente provava execução, continuidade, cobrança ou resultado.
  • AMBIGUOUS, NO_SUCH_FLOW e a ausência de uma análise de segurança mostram que decisão e realidade operacional precisavam ser reconciliadas.

Em março de 1997, o RFC 2124 propôs uma saída pragmática para a falta de uma representação padronizada de políticas de conexão. A Connection Control Entity (CCE) de um switch ATM perguntaria a um Flow Admission Service (FAS) externo se um fluxo poderia ser estabelecido. Assim, uma organização poderia aplicar política comum sem fazer cada fabricante implementar sua linguagem interna.

O registro do RFC Editor e a página do IETF Datatracker deixam claro que o texto era Informational, não um Internet Standard. Ele descrevia uma interface, não comprovava adoção.

O switch começava a conversa e a conexão

Antes de criar o fluxo, a CCE enviava um Flow Admission Request (FAR). O pedido podia levar identificador, endereços, serviço, dados do cliente e horário do switch. O FAS respondia com um Flow Admission Acknowledge (FAA), capaz de aceitar, rejeitar, anexar políticas ou indicar outro destino.

Esse FAA era o veredito do serviço sobre os dados recebidos. Não era a conexão. Uma política opcional desconhecida podia ser ignorada; uma política obrigatória desconhecida exigia que a CCE abortasse o fluxo e enviasse um Flow Admission Update. O projeto não escondia a diferença entre querer uma regra e conseguir executá-la.

Um FAR provava que o switch pediu. Um FAA SUCCESS provava que o FAS aceitou. Só a evidência posterior do dispositivo poderia dizer o que ocorreu.

Estado e contadores chegavam por outro caminho

Depois do estabelecimento, Flow Update Notifications (FUN) informavam horário, estado, bytes e pacotes, células ou quadros. Elas podiam ser periódicas, motivadas por mudança ou solicitadas.

Havia contadores acumulados desde o começo e contadores de diferença desde o FUN anterior. Sem registrar o tipo, uma soma podia parecer completa sem nunca ter sido afirmada por nenhuma ponta. Mesmo um número correto não provava autorização do usuário, entrega à aplicação ou validade de uma cobrança.

No Flow Update Acknowledge (FUA), SUCCESS tinha um significado limitado e importante: o FAS aceitara as informações do FUN e passava a responder por elas. Era custódia informacional, não garantia de armazenamento durável, completude, sincronização de réplicas ou serviço ao cliente.

O FAS ainda podia mandar um Flow Change Request (FCR) para alterar política ou parar o fluxo. O switch devolvia um Flow Change Acknowledge (FCA). POLICY_REJECT mostrava uma mudança não suportada; NO_SUCH_FLOW, a ausência de estado. O controle continuava sendo uma negociação verificável, não uma consequência automática da admissão inicial.

O pedido completo definia a repetição segura

Se um Flow ID repetido viesse num FAR idêntico ao anterior, salvo talvez o Message ID, o FAS repetia a resposta. Se o conteúdo diferisse, devolvia AMBIGUOUS e exigia outro identificador. A idempotência dependia da solicitação inteira.

NO_SUCH_FLOW também explicitava perda de estado no FAS: uma atualização podia mencionar conexão nunca admitida ou já esquecida. Em sentido oposto, o switch podia não reconhecer um FCR. O protocolo obrigava a enfrentar a divergência.

Para failover, um prefixo do FAS junto ao identificador da CCE pretendia manter unicidade global. Sem suporte ao prefixo, uma chamada poderia parecer duas no acumulador depois da troca de FAS. O nome ajudava a correlacionar; não certificava que as instâncias tinham o mesmo histórico.

A política era central; a segurança ficou fora

O FAS concentrava poder para negar, redirecionar e parar conexões. Ainda assim, a seção Security Considerations diz apenas que o memorando não discute segurança. Uma sessão TCP não autenticava por si só a origem da política. O atual registro da IANA lista csi-lfap na porta 3145 e registra, separadamente, uso não autorizado conhecido dessa porta.

O recorte difere dos artigos próximos. RFC 2063 apresenta a arquitetura de medição; a análise BTW existente trata da lacuna temporal da leitura assíncrona. RFC 2123 documenta o NeTraMet; a análise existente trata da projeção por regras. O RFC 2124 trata da passagem entre veredito central, ação do switch e registro reconciliado.

A primazia do código em execução, a especificação inicial mínima e decisão futura localizada e as camadas de realidade de Heng Lu ajudam a nomear a disciplina: uma representação administrativa não substitui o fato executado.

LFAP antecipou o controle programável, mas seu melhor legado é o limite. A decisão central só é confiável quando os comprovantes de execução, estado e uso continuam visíveis.

Fontes