Resumo

  • A RFC 1434 encerrava LLC Type 2 em cada Data Link Switch, formando duas conexões locais independentes em vez de um único enlace que atravessasse a WAN.
  • Por SSP, os switches ainda precisavam descobrir a estação, trocar dois Circuit IDs de significado local e concluir o contato; uma conexão TCP estabelecida não comprovava essas etapas.
  • O desenho protegia temporizadores de LAN e retirava confirmações da WAN, mas a multiplexação criava destino comum: uma falha de TCP derrubava todos os circuitos transportados por ela.

A demora da WAN não cabia no relógio da LAN

LLC Type 2 foi concebido para um ambiente em que o atraso de trânsito fosse pequeno e previsível. Um temporizador fixo ajudava a identificar uma trama perdida. Quando uma ponte prolongava essa relação por um circuito de longa distância lento ou congestionado, uma trama apenas atrasada parecia perdida. A retransmissão podia desorganizar o procedimento e, no limite, levar à queda do enlace.

Data Link Switching mudou o lugar onde a relação terminava. O terminal de um lado mantinha LLC com o switch próximo; o terminal do outro lado mantinha outra LLC com seu próprio switch. O controle de enlace não cruzava a WAN. Entre os dois Data Link Switches, o Switch-to-Switch Protocol retransmitia a informação por transporte confiável.

Assim, timeouts, confirmações LLC e o polling de SDLC ficavam perto do equipamento a que pertenciam. Cada DLS podia absorver tentativas e aplicar pressão de retorno localmente. A variação do caminho amplo deixava de comandar diretamente um procedimento feito para um anel local.

Mas a confirmação mudou de alcance. Um RR ou UA visto pelo terminal significava que o switch adjacente havia assumido uma obrigação local. Não significava recepção pela estação remota, estabelecimento da LLC do outro lado nem execução pelo aplicativo. A RFC chamou as duas conexões LLC de totalmente independentes; a continuidade percebida era construída sobre responsabilidades separadas.

Um transporte para muitos circuitos

Dois DLS primeiro estabeleciam uma conexão de transporte. A implementação inicial usava TCP, ainda que o documento admitisse outro transporte confiável. Só então SSP montava os circuitos de ponta a ponta entre switches. Vários circuitos podiam compartilhar a mesma conexão.

O estado de TCP, portanto, falava dos dois switches. Não dizia onde estava a estação pedida, qual peer a alcançava, se os identificadores tinham sido combinados ou se o enlace remoto aceitara contato. Um painel que promovesse “socket conectado” a “serviço do terminal ativo” atravessaria vários limites sem evidência.

O Data Link ID representava os dois pontos terminais por suas combinações de endereço MAC e SAP. Para a instância do circuito, cada switch atribuía localmente um Circuit ID de 64 bits, composto por DLC Port ID e Data Link Correlator. O circuito de ponta a ponta exigia o par; cada DLS guardava a correspondência entre o valor local e o remoto.

Antes desse par, as mensagens carregavam o Data Link ID mais longo. Depois do estabelecimento, INFOFRAME podia usar um cabeçalho menor, com o Circuit ID remoto. A economia deslocava contexto para a tabela do switch. Um identificador sozinho não é global e não permite correlacionar os dois lados sem o peer, a direção e o número correspondente.

Descobrir não era contatar

CANUREACH perguntava se algum DLS podia chegar à estação. ICANREACH respondia positivamente e entregava o Circuit ID do alvo. REACH_ACK completava a troca ao devolver o Circuit ID da origem. Em seguida, CONTACT e CONTACTED tratavam do contato com a estação remota.

Os nomes mantinham as afirmações estreitas. Peer disponível não era localização conhecida. Resposta de alcance não era par de identificadores completo. Circuito identificado não era enlace remoto contatado. Cada transição removia uma incerteza específica e podia falhar sem invalidar as observações anteriores.

Uma busca podia receber vários ICANREACH. A origem selecionava o primeiro e encaminhava REACH_ACK ao escolhido. A localização operacional, portanto, era um resultado observado e selecionado em determinado momento. Guardar apenas o vencedor elimina os demais candidatos e a ordem que decidiu a rota do circuito.

O cache reduzia a expansão da busca. Sem uma entrada, o switch podia enviar CANUREACH ou consultas NetBIOS a todos os peers conhecidos. Uma localização recente economizava tráfego; uma antiga levava tentativas para um ponto que já não servia. Proveniência e validade temporal do cache pertenciam ao diagnóstico.

A confirmação local podia chegar primeiro

Ao receber SABME da estação, o DLS de origem podia responder UA localmente antes de o destino remoto estar contatado. Para evitar que a estação começasse a transmitir cedo demais, o switch colocava-a em RNR. Só depois de receber CONTACTED liberava o fluxo com RR.

O UA não fingia uma resposta do destino. Ele registrava que o switch assumira o enlace local. O RNR mantinha explícita a pendência seguinte. A leitura errada surge quando monitoramento ou lógica comercial transforma a aceitação do intermediário em aceitação do usuário distante.

Circuito SSP, contato remoto, permissão de envio e resposta da aplicação precisam de registros diferentes. Mesmo que TCP entregue bytes em ordem ao DLS do outro lado, sua LLC local pode estar repetindo ou encerrando, e o programa final pode não ter processado nada.

A RFC 1795, sucessora, reforçou essa fronteira com pacing adaptativo por circuito e por direção. Após troca de capacidades, o emissor começava sem unidades concedidas e dependia de FCIND para obter autorização. O recurso é de 1995 e não deve ser atribuído à RFC 1434; ele mostra, porém, que transporte confiável não determinava a cota de cada circuito lógico.

A falha comum aparecia nas pontas

Encerrar LLC localmente diminuía confirmações na WAN. Multiplexar circuitos reduzia a quantidade de transportes. O mesmo ganho criou uma dependência comum no centro.

Segundo a RFC 1434, se a conexão TCP entre os Data Link Switches falhasse, todas as conexões multiplexadas sobre ela seriam derrubadas. Os dois DLS enviariam DISC a todos os sistemas locais envolvidos. Um terminal poderia ter cabo, porta e enlace adjacente em boas condições e ainda perder a sessão por causa do transporte compartilhado.

Dez desconexões no mesmo instante poderiam resultar de uma única falha de TCP. Contá-las como dez causas distorceria o incidente. Registrar só a conexão comum esconderia a extensão. O modelo correto liga uma causa a todos os Circuit IDs afetados, a seus dois enlaces locais e aos usos finais.

Outras quedas tinham percurso diferente. HALT_DL e DL_HALTED coordenavam a parada de um enlace; um erro DLC local podia levar um único circuito à desconexão. A tela do terminal mostrava o mesmo resultado. A primeira transição de estado dizia qual autoridade e qual camada deviam responder.

As versões seguintes ganharam instrumentos

A RFC 1795 declarou mudanças significativas e substituiu a RFC 1434. O grupo DLSw do APPN Implementers Workshop procurava um SSP único, implementável por diferentes fornecedores, e corrigia problemas de documentação. Incluiu troca inicial de capacidades entre a formação do transporte e as mensagens normais de circuito.

A RFC 2024 converteu essas fronteiras em objetos de gestão. O transporte podia estar conectando, em troca inicial de capacidades, conectado, em quiescência, desconectando ou desconectado. Havia contadores de exploração e criação de circuitos, além de razões de encerramento. Operação passou a enxergar estados que um indicador TCP único apagaria.

A RFC 2166 registrou os custos de escala: administrar muitos peers, replicar descoberta e NetBIOS em conexões ponto a ponto, manter transportes e terminar grandes quantidades de LLC2. O DLSw v2.0 acrescentou motivos de HALT, descoberta com multicast, conexões sob demanda e preferência por uma conexão TCP bidirecional quando possível.

Essas funções posteriores não pertencem ao desenho original. Elas revelam que o estado removido da WAN e dos terminais não desapareceu. Passou a morar nos switches, exigindo negociação, observabilidade e controle de escala.

A prova não termina no INFOFRAME

Um histórico útil relaciona peer e estado de transporte, Data Link ID pesquisado, todos os ICANREACH, escolha feita, ambos os Circuit IDs, CONTACT/CONTACTED, DLC de cada ponta, permissão de fluxo, contadores e primeira razão de queda. Só depois vem a evidência da aplicação.

As RFCs 1434 e 1795 dizem expressamente que não discutem segurança. Elas não bastam para provar autenticação de peer, autorização da estação, confidencialidade ou integridade contra adversários. Confiabilidade de transporte dentro do modelo não é conclusão de segurança.

Também não comprovam implantação, adoção atual ou incidente real. Seu valor histórico está na forma de raciocinar: um serviço aparentemente contínuo pode depender de contratos locais. Para saber onde terminou a promessa, transporte, circuito, contato, enlace e aplicação precisam permanecer fatos separados.

Fontes