Resumo

  • A TUBA manteria TCP, UDP e muitas aplicações da Internet, mas substituiria IPv4 por CLNP e pelos endereços NSAP, mais estruturados.
  • O plano dependia de mais que roteadores compatíveis: hosts, DNS, aplicações que carregavam endereços IPv4, agregação de rotas e autoridade para manter o CLNP também eram decisivos.

O que seria preservado — e o que mudaria

Em junho de 1992, Ross Callon publicou a proposta RFC 1347, chamada TUBA, sigla de “TCP and UDP with Bigger Addresses”. O documento respondia a duas pressões conectadas: os endereços IPv4 de 32 bits se tornavam limitados, enquanto cresciam rapidamente as informações de rota nas redes centrais. A proposta não ampliava o IPv4. Ela trocava a camada de rede: TCP ou UDP passariam a rodar sobre o protocolo sem conexão CLNP, da arquitetura ISO, e endereços NSAP substituiriam os endereços IP.

A promessa de continuidade era real, porém delimitada. Um navegador, cliente de e-mail ou programa de transferência de arquivos poderia seguir usando TCP ou UDP se não dependesse de endereços IPv4 embutidos em seu próprio protocolo. Embaixo desses transportes, o pacote, o endereçamento e o encaminhamento seriam diferentes. Callon destacava que o CLNP já oferecia serviço de datagramas e estava presente em algumas redes regionais e de backbone da Internet. Reaproveitar esse trabalho poderia evitar criar e testar outra camada de rede do zero.

A TUBA não pedia que toda a Internet adotasse os protocolos OSI. O objetivo era substituir IP e manter os transportes e muitas aplicações. Publicada como experimental em dezembro de 1993, a RFC 1561 definiu um perfil de CLNP para esse ambiente. Ela também reconheceu que IP e CLNP ofereciam serviços semelhantes, mas não idênticos; o perfil precisava preservar significados de informações esperadas pelos protocolos da Internet.

DNS e hosts também faziam parte do caminho

A RFC 1347 imaginava hosts antigos e atualizados convivendo. Ao consultar o DNS, um host novo receberia o endereço IP comum de um destino antigo e usaria a pilha já existente. Se recebesse um NSAP mais longo de outro host compatível, enviaria TCP ou UDP por CLNP. O DNS precisava então entender um registro “long-address”. Os roteadores teriam de encaminhar IP e CLNP de forma independente, por meio de equipamentos multiprotocolo ou conjuntos separados. A resposta de endereço indicaria qual protocolo usar; não seria necessário traduzir ou encapsular cada pacote entre os dois.

Uma implantação em etapas não eliminava as dependências. Um host atualizado poderia continuar em uma rede sem serviço CLNP. Alguns usos de FTP e NFS carregavam endereços IP nos dados da aplicação, o que exigiria mudanças mesmo com TCP mantido. Hosts, DNS e operadores de rede precisavam avançar em conjunto. E endereços maiores, sozinhos, não produziam rotas compactas: a alocação NSAP tinha de acompanhar a topologia para permitir agregação.

Um argumento a favor da TUBA era a existência de roteadores capazes de CLNP. A revisão de janeiro de 1995 em RFC 1752 registrou uma diferença importante: os avaliadores viam presença significativa de roteadores compatíveis, mas havia menos concordância sobre hosts CLNP e redes realmente operadas com CLNP. Um roteador que sabe encaminhar pacotes é um recurso útil; ele não prova que aplicações conseguem se comunicar de ponta a ponta.

Reutilizar CLNP também trazia uma questão de controle

A RFC 1752 registra preocupações com o alinhamento dos campos do cabeçalho, o roteamento de origem, mensagens de erro e o uso de NSAP para agregar rotas. Resolver alguns problemas poderia exigir alterar o CLNP ou o perfil adotado. A comunidade da TUBA não concordava sobre quem podia fazer isso: o IETF poderia mudar a especificação básica de um protocolo ISO ou seria necessário seguir o processo da ISO? A resposta afetaria a velocidade de correção e a responsabilidade por manter a camada que a Internet passaria a usar.

A recomendação de IPng não apagou o trabalho da TUBA. Depois de avaliar várias propostas, a RFC 1752 recomendou o SIPP revisado como base do IPng. O documento também descreve uma síntese: o SIPP forneceu a maior parte do protocolo-base, enquanto a TUBA influenciou a autoconfiguração e os mecanismos de transição. O CLNP não substituiu o IP na Internet, mas a trajetória da TUBA não terminou sem contribuições.

A posterior Note:64 de Heng Lu serve como lente retrospectiva, não como prova sobre aquele período: quais regras comuns são indispensáveis, quais escolhas podem ficar com os implementadores e que evidência mostra adoção? A TUBA ajuda a responder porque reaproveitar um protocolo pode reduzir invenções, sem resolver quem o mantém, quais hosts o implementam e quais redes de fato o transportam.

Fontes