O portador não era a conexão: como a RFC 892 separou o estado de transporte do caminho de rede

Resumo

• A RFC 892 identificava a Transport Connection por duas referências escolhidas pelos pares, não pela Network Connection que transportava seus TPDUs.
• Multiplexing permitia várias conexões de transporte em uma conexão de rede; splitting permitia, na classe apropriada, uma conexão de transporte sobre várias conexões de rede.
• O desacoplamento era limitado por qualidade, custo, funções pervasive, classe confirmada e regras de recuperação. O portador não definia sozinho o estado, mas continuava impondo realidade.

A RFC 892 trabalha com duas unidades de continuidade. A Network Connection (NC) é o serviço inferior entre entidades de transporte. A Transport Connection (TC) é o estado oferecido aos usuários de transporte. Um TPDU precisa passar pela primeira para participar da segunda.

Antes de usar uma TC, a entidade devia atribuí-la a uma NC, ou a várias quando splitting estivesse ativo. Uma conexão inferior existente poderia servir, ou outra seria criada. Essa escolha era operacional e local. Não substituía as referências nem a confirmação entre os pares.

O texto chegou à série RFC apenas como informação. Ele dizia expressamente que não era padrão para a ARPA Internet. A RFC 905 a superou com uma edição posterior do ISO DP 8073, ainda sob a mesma fronteira. Preservar a especificação não significava adotar a pilha OSI como arquitetura da Internet.

A referência era escolhida para o outro usar

O iniciador enviava um Connection Request TPDU, o CR, com sua source reference. O respondente devolvia um Connection Confirm, o CC, com a referência que escolhera. A partir daí, cada lado usava o número do outro como destination reference.

O campo tinha 16 bits e valor local. Zero era proibido; referências ativas ou ainda frozen também não podiam ser reutilizadas. Não era nome global, identidade de organização ou credencial. Funcionava como chave para uma entrada viva na tabela do receptor.

Essa criação bilateral era simétrica. Dispensava uma relação master/slave e ajudava a evitar colisão de chamadas. RFC 892 afirmou que o mecanismo identificava a TC independentemente da NC.

A frase não autorizava trocar o portador arbitrariamente. O TPDU ainda precisava aparecer numa atribuição reconhecida, na fase correta e entre entidades inferidas pelos endereços de rede. A referência provava associação a estado, não autenticidade humana, permissão nem sucesso do aplicativo.

A classe começava como expectativa e terminava como seleção

As cinco classes davam respostas diferentes ao serviço inferior. Class 0 era simples. Class 1 recuperava falhas sinalizadas. Class 2 multiplexava. Class 3 combinava recuperação e multiplexing. Class 4 detectava e recuperava perda, duplicação, dano e reordenação.

No CR, o iniciador indicava uma preferred class e alternativas, salvo quando preferia class 0. Podia iniciar funções supondo que a preferência seria aceita. Era uma antecipação reversível. O CC trazia a selected class e obrigava o iniciador a se ajustar quando o respondente escolhia outra alternativa permitida.

O tamanho máximo de TPDU tinha seu próprio acordo. O respondente podia aceitar a proposta ou reduzir o valor dentro do conjunto permitido. Options passavam de proposed para selected. O fato de a NC estar de pé não provava a classe, o tamanho, as opções nem a existência final da TC.

O caminho também influenciava a escolha. A RFC classificava Network Services por erros residuais e falhas sinalizadas, além de considerar requisito e custo do usuário. Uma NC alcançável podia ser inadequada por qualidade ou porque uma função pervasive já usada nela entrava em conflito com a nova TC.

Reutilizar o mesmo suporte criava separação e acoplamento

Com multiplexing, várias TC compartilhavam uma NC. Cada TPDU levava destination reference para o estado correspondente. A economia de abertura e capacidade não transformava conversas diferentes em uma só.

Entretanto, funções pervasive pertenciam ao portador compartilhado. Se a primeira TC usasse uma delas, as demais na mesma NC teriam de usá-la durante a vida daquela conexão. O suporte não era a identidade, mas tinha poder de impor uma condição comum.

Splitting and recombining invertia a cardinalidade: uma TC usava várias NC para resiliência, throughput ou outro objetivo. A tabela de RFC 892 limitava o recurso à class 4. A história correta não diz que todo ISO transport era multipath; diz que o protocolo representava separadamente um estado e seus vários portadores.

Reassignment permitia a continuidade depois de uma desconexão inferior nas classes de recuperação que o invocavam. A TC passava a outra NC e executava resynchronization. Um TPDU válido no novo suporte, os endereços coerentes e as referências existentes forneciam evidência para o par reconhecer a atribuição.

Class 0 marcava a exceção estrutural. Não havia release de transporte independente, e a vida da TC se correlacionava diretamente à NC. Logo, a independência precisava ser provada pela class selecionada, não inferida do diagrama de camadas.

O contrato foi levado para cima do TCP

A RFC 983 propôs oferecer ISO TSAP sobre TCP/IP. As entidades superiores ISO poderiam usar a interface sem saber qual serviço inferior a sustentava. O documento não afirmou ser um plano completo de migração.

A RFC 1006 substituiu a proposta com a versão 3 e padronizou transport class 0 sobre TCP. Como TCP fornece stream de octetos e TP0 espera unidades discretas, cada TPDU ganhou um contêiner de comprimento conhecido, o TPKT. A fronteira ajudava a enquadrar; não autenticava nem protegia integridade.

No mapeamento, TCP open virava estabelecimento do serviço inferior e TCP close virava disconnect. O uso de class 0 aproximava as duas vidas. Mesmo assim, o contrato de ISO transport podia continuar sobre um portador diferente daquele pressuposto pelo texto original.

A RFC 2126 refinou o modelo para TCP em IPv4 ou IPv6, com variantes class 0 e class 2. Preservou a versão do TPKT para proteger a base RFC 1006 e observou que a porta TCP 102 era reservada sem ser obrigatória para toda conexão.

O registro IANA de nomes de serviço e portas registra iso-tsap em 102. Isso prova coordenação do número, não implementação em execução, classe confirmada, referência viva ou transação concluída.

Fontes e limites

O artigo usa RFC 892, RFC 905, RFC 983, RFC 1006, RFC 2126 e o registro IANA. As fontes estabelecem desenho, status documental e mapeamento sobre TCP. Não estabelecem implantação atual, adoção geral de OSI, linhagem direta para QUIC ou SCTP, suporte universal a splitting, autenticação ou comportamento de um produto específico.