Resumo

  • Na RFC 2024, uma linha do diretório dizia onde um nó DLSw acreditava alcançar um endereço MAC ou nome NetBIOS; não dizia que o circuito da estação estava ativo.
  • Transporte, circuito, controle de ritmo e dados de desconexão respondiam a perguntas diferentes e precisavam permanecer ligados como evidência.

Uma pergunta operacional costuma chegar ao painel de forma simples: o recurso está acessível? A RFC 2024 respondeu com várias tabelas. O diretório indicava uma localização. A tabela de transporte mostrava se os pares DLSw haviam concluído a troca de capacidades. A tabela de circuitos acompanhava um caminho entre estações. Os objetos de ritmo informavam quantas mensagens ainda podiam ser enviadas antes de esperar. Nenhum desses registros produzia a condição descrita pelo outro.

O diretório guardava uma crença de localização

As tabelas de MAC e NetBIOS associavam cada recurso a um ponteiro. Ele podia levar a uma interface local, a uma conexão configurada, a uma conexão operacional, a uma referência nula ou a uma tabela da implementação. O estado — desconhecido, alcançável ou inalcançável — registrava o que o DLSw acreditava naquele momento sobre o acesso por aquele local.

Os exemplos estáticos conservam a incerteza. Uma entrada podia começar desconhecida. O mesmo recurso remoto podia aparecer por vários parceiros. A ordem dos candidatos não era garantida, e um empate entre informação estática e dinâmica igualmente específica podia depender do produto. Depois de uma busca malsucedida, uma entrada inalcançável podia existir principalmente para evitar a repetição imediata.

Assim, o diretório reduzia o espaço de busca. Não comprovava conexão do par escolhido, início do estabelecimento do circuito nem resposta da estação final.

O transporte seguia outro relógio

A conexão operacional passava por estados como conectando, troca inicial de capacidades, conectado, aquiescendo, desconectando e desconectado. Conectado queria dizer que os pares haviam determinado suas capacidades e estavam prontos para mensagens de estabelecimento de circuito. Não era sinônimo de serviço ponta a ponta.

O vínculo com a configuração também podia envelhecer. dlswTConnOperConfigIndex apontava para a linha que governava a conexão, mas virava zero quando ela era apagada. Uma alteração feita depois da conexão podia não representar todas as condições negociadas anteriormente. Por isso, o horário da conexão e a última modificação da configuração precisavam ser comparados.

Uma implementação ainda podia manter a linha depois da desconexão para preservar estatísticas e causa, sem prazo obrigatório. Capacidades recebidas do parceiro podiam continuar legíveis ali. Um campo preenchido numa linha histórica não demonstrava disponibilidade presente.

O circuito só surgia depois da descoberta

A RFC 2024 separava a ativação em dois momentos. Mensagens exploratórias localizavam o endereço ou nome; depois começava o estabelecimento do circuito. A linha de circuito aparecia apenas nesse segundo momento.

O circuito tinha uma sequência de estados própria. Seu único estado gravável era disconnectPending; não havia comando de gerência para restabelecê-lo, pois as estações finais iniciavam a criação. Motivos de desconexão e referências às MIBs LLC ou SDLC inferiores ajudavam a investigação. Algumas estatísticas de tráfego exigiam seguir essas referências. Eram pistas, não um laudo automático de causa raiz.

Os créditos de ritmo tinham escopo igualmente exato: quantas mensagens SSP com pacing um lado estava autorizado a enviar antes de parar. Zero também podia indicar ausência de pacing. A janela atual ou máxima não contava mensagens entregues nem trabalho concluído.

A notificação registrava uma transição

Traps podiam ser emitidas quando transporte ou circuito entravam em conectado, mas a emissão era configurável e podia ser desativada. Uma trap recebida provava que um agente local reportou a transição e que o aviso chegou. Não provava permanência, concordância do outro par ou ausência de queda posterior. A falta de trap tampouco provava que a transição não ocorreu.

Horário e motivo da desconexão e o indicador de circuitos ativos estreitavam o incidente. Este último dizia que usuários podiam ter sido afetados, sem contar pessoas ou mensurar perda de negócio. A RFC 2166 adicionou depois à RFC 1795 razões HALT gerais, próximas de categorias como desconexão pela estação, erro DLC, erro de protocolo do circuito e ação do operador. Pares antigos podiam omitir a razão; detalhes de fornecedor variavam. A pista melhorava, mas não virava causa definitiva.

A visão completa podia estar nos dois lados

A RFC 2024 reconhecia que uma imagem completa poderia exigir consultas a vários nós DLSw. Para evitar duplicação, certas informações eram definidas como recebidas do parceiro. O protocolo também não oferecia uma forma de correlacionar o endereço de transporte gerenciado do parceiro ao seu endereço de gerência.

Cada linha era, portanto, um testemunho local com escopo. A distinção de Heng Lu entre um registro e a realidade descrita oferece uma lente atual: o registro pode estar correto sem conter todo o estado operacional. É uma aplicação analítica, não uma afirmação sobre a intenção dos autores da RFC.

A solução é preservar as junções. O diretório sustenta a crença de localização; o transporte, o estado e o tempo da negociação; o circuito, o caminho das estações; as MIBs inferiores, a evidência da ligação local. Comparadas entre os pares, as tabelas explicam o serviço. Reduzidas a uma luz verde, escondem a diferença decisiva.

Fontes