Resumo

  • O RFC 3395 acrescentou verbos de aplicação aos identificadores RMON, embora uma transação pudesse atravessar vários pacotes e depender de uma requisição observada no sentido oposto.
  • Cada pacote ainda precisava ser contabilizado uma única vez sob uma folha completa. Quando carregava vários verbos, o agente escolhia um segundo uma política própria que o padrão não uniformizou.

Uma Response PDU do SNMP chega à sonda. Ela é uma resposta, mas a qual operação? O pacote atual não revela se veio de Get ou GetNext. Para dar nome correto aos seus octetos, a sonda procura na memória a requisição anterior, vista no sentido contrário. Antes de existir um contador de verbo, existia uma correlação.

Publicado em setembro de 2002 na trilha de padrões, o RFC 3395 atualizou a referência de identificadores de protocolo do RFC 2895. O RMON já separava protocolos, mas totais de HTTP, SNMP ou FTP não distinguiam operações com custos e significados operacionais diferentes. A extensão criou um vocabulário comum para transações de aplicação. Não criou módulo MIB novo nem novas operações de gerenciamento.

O diretório de protocolos tratava o pacote como uma pilha reconhecida. Cada camada acrescentava quatro octetos a protocolDirID e um a protocolDirParameters; a sequência inteira identificava a folha do encapsulamento. O verbo de aplicação passou a ocupar mais uma camada dessa sequência.

Sua codificação tinha quatro octetos: um primeiro octeto reservado em zero e uma enumeração sem sinal de 24 bits em ordem de rede. Os valores explícitos iam de 1 a 16.777.215, tinham de ser exclusivos dentro do protocolo pai e deveriam ser atribuídos de modo denso. Um byte zero era anexado aos parâmetros, sem uso semântico, para preservar a forma regular da estrutura.

O zero já possuía autoridade própria. Todo protocolo de aplicação recebia implicitamente connect(0), destinado ao estabelecimento e encerramento de sessão não atribuídos a outro verbo. A enumeração não podia ser redefinida. Já a palavra não era proibida: no exemplo de HTTP, o método CONNECT também surgia como connect(8). O pai e o número eram indispensáveis para não confundir rótulos familiares.

A macro VERB-IDENTIFIER reunia o protocolo pai, uma descrição obrigatória, uma referência aconselhável quando existia fonte normativa e a lista de nomes e números. Os nomes distinguiam maiúsculas de minúsculas e eram únicos dentro do pai. Usar a terminologia oficial favorecia interoperabilidade, mas a identidade do nome não eliminava as diferenças de observação.

O tempo era o primeiro limite. No exemplo SNMP, Response e Report não constituíam verbos separados: eram atribuídos à transação da requisição. Isso exigia estado. Em TCP, a dificuldade aumentava, porque uma operação podia estar dividida em segmentos. A sonda precisava acompanhar o fluxo e remontar bytes suficientes antes de decidir.

Se a política de captura dependesse do verbo, a decisão poderia chegar tarde. Os primeiros pacotes da transação já teriam passado. Um pré-buffer preservava esse início enquanto a classificação aguardava evidência posterior; sem ele, a captura específica da operação começava incompleta.

Por isso, verbo não significava necessariamente comando, opcode ou tipo de PDU. Uma transação podia juntar vários tipos de mensagem e até mais de uma entrada do diretório. Em FTP, a conversa de controle e a conexão de dados podiam pertencer à mesma ação útil. O verbo era uma unidade de análise, não um campo garantido em todo pacote.

Mesmo assim, a contabilidade do RMON exigia uma saída única. Cada pacote era contado uma vez sob um encapsulamento folha completo, somando ao contador seu tamanho integral. Se aparecessem vários verbos, não se dividiam os bytes entre eles. O agente era obrigado a selecionar um.

O RFC sugeriu critérios possíveis: o primeiro verbo, o mais frequente, o que ocupasse mais octetos ou o considerado mais interessante pelo conhecimento do protocolo. Nenhum virou regra universal. Duas sondas conformes podem, portanto, receber a mesma captura e apresentar distribuições diferentes sem que uma delas esteja necessariamente errada.

Os exemplos de FTP, POP3, SNMP, HTTP e SMTP facilitavam o registro, mas não transformavam contagem em prova de intenção. GET não identifica uma pessoa, não demonstra autorização, sucesso da transação ou visibilidade completa do conteúdo. Indica que determinado agente, com certo estado e uma política local, atribuiu pacotes àquela folha.

A seção de segurança reconhecia uma consequência adicional. Embora a extensão não acrescentasse operações MIB, a coleção por verbos revelava quais operações de aplicação estavam em uso. Essa informação mais fina podia exigir proteção adicional. Maior resolução de medição também significava maior resolução de exposição.

Mais tarde, o RFC 4502 substituiu o RFC 2021 como especificação do RMON-2. A sucessão localiza a arquitetura, porém não prova adoção universal do RFC 3395 nem comportamento igual diante de perda, criptografia, rota assimétrica ou esgotamento de estado. O padrão fornece o contrato; o sistema em execução fornece a evidência.

O princípio de especificação inicial mínima de Lu Heng explica a fronteira. O documento fixou codificação, parentesco, nomes, valor reservado, capacidades e o dever de escolher uma folha. Tempos, buffers, remontagem e preferência entre verbos permaneceram locais, evitando congelar uma heurística antes de conhecer todos os protocolos e limites operacionais.

A primazia do código em execução exige guardar junto do número a versão da sonda, decodificadores, capacidade de estado, perdas, regras de remontagem e de seleção. Sem essa proveniência, um nome comum torna os painéis parecidos, mas não garante que tenham observado do mesmo modo.

O legado do RFC 3395 está nessa honestidade. O pacote era recebido; a transação era inferida. Quando o contador dizia GET, ele carregava simultaneamente o tráfego da rede, a memória da sonda e a decisão que transformara várias possibilidades em uma só.

Fontes