Resumo

  • A RFC 1070 envolvia PDUs da camada de rede OSI em datagramas IP. Com isso, implementadores podiam testar roteamento OSI entre locais distantes sem instalar protocolos imaturos nos gateways já usados pela Internet.
  • O transporte IP não determinava quem era vizinho no EON. Endereço NSAP, lista core.EON, cache SNAcP, papel de sistema final ou intermediário e aprendizado por protocolos de roteamento descreviam estados diferentes, sujeitos a divergência.

A RFC 1070, de fevereiro de 1989, queria oferecer escala a uma experiência sem transferir o risco para a infraestrutura que lhe dava escala. Protocolos de rede OSI ainda precisavam ser submetidos a uma topologia grande, variada e mutável. Alterar muitos gateways IP para esse fim poderia perturbar um serviço existente com código cuja maturidade era justamente o objeto do teste.

O memorando encontrou uma assimetria útil. A Internet já conectava os laboratórios. Ela poderia transportar o PDU completo de CLNP, ES-IS ou IS-IS como dados de um pacote IP, sem que os gateways soubessem interpretar OSI. Dentro de uma rede local, os participantes usariam a camada OSI diretamente. Fora dela, tratariam a Internet como uma sub-rede, chamada de IP subnet. A rede experimental acima recebeu o nome EON.

O texto não apresentou isso como solução operacional. Pelo contrário, estampou um aviso de uso limitado e experimental. Também excluiu escala de produção, formatos NSAP arbitrários, adoção obrigatória de todos os protocolos OSI, uso do algoritmo de roteamento IP para encaminhar ISO-grams entre participantes e conversão IP-CLNP.

A camada inferior sabia alcançar, não sabia classificar

No EON direto, o ISO-gram inteiro entrava no campo de dados de um pacote IP, identificado pelo número de protocolo 80. A fragmentação deveria ocorrer preferencialmente no CLNL, pois o comportamento OSI precisava ser exercitado. Ainda assim, o caminho podia fragmentar o pacote IP, e o destino tinha de recompor também essa camada.

Essa dupla possibilidade torna a evidência granular. Receber um fragmento IP não estabelece a reconstrução do PDU superior. Reconstituí-lo não estabelece que uma função ES ou IS o aceitou. Processá-lo não estabelece uma rota aprendida. A mesma cautela vale para a conectividade: a RFC esperava que várias máquinas de um local fossem alcançáveis por IP, mas que só um subconjunto se declarasse diretamente conectado ao EON.

O formato de endereço aproveitava a proposta da RFC 1069. Os quatro octetos do endereço Internet apareciam na parte final do NSAP, antes do seletor. Dessa forma, a SNPA do IP subnet podia ser derivada. IANA fornecia o número do domínio de roteamento e, inicialmente, a área local era zero.

O cálculo fornecia um ponto de envio. Não dizia se a máquina funcionava como ES, IS ou ambos, nem se outra máquina a considerava a um salto de distância. Os papéis podiam mudar sem mexer na conexão física. A proposta procurava deliberadamente preservar o roteamento e o endereçamento OSI como objeto do experimento, e não substituí-los pelo sucesso prévio da Internet.

SNAcP criou um meio compartilhado a partir de cópias privadas

Os protocolos ES-IS e IS-IS pressupunham destinos para todos os sistemas finais e todos os intermediários em uma sub-rede de broadcast. O IP subnet, tal como aparecia às implementações, não entregava essa abstração. RFC 1070 introduziu SNAcP entre OSI CLNL e IP.

Cada instância mantinha um cache de endereços Internet considerados alcançáveis em um salto ISO 8473. Para envio individual, encaminhava uma cópia. Para todos os ESs, todos os ISs ou broadcast, repetia o ISO-gram uma vez para cada SNPA do cache. Um cabeçalho curto trazia versão, significado do destino e checksum Fletcher. Na entrada, a configuração local decidia se uma mensagem de todos os ESs ou todos os ISs cabia ao papel da máquina.

O “broadcast” não era uma propriedade universal da infraestrutura. Era a enumeração que o remetente tinha naquele momento. E a participação no grupo não era decidida pelo endereço IP: era a interpretação do receptor. Uma cópia entregue demonstrava o caminho até aquela SNPA, não a completude do conjunto nem a atualidade de todos os papéis.

Sinais ICMP podiam alterar esse estado. Destination unreachable, parameter problem e time exceeded serviam para marcar uma entrada como inutilizável; source quench podia suspender seu uso por algum tempo. A ação administrativa ficava inteiramente local, chegando à possibilidade de não fazer nada. Em multicast simulado, entradas inutilizáveis eram puladas; em envio individual, o erro voltava ao CLNL. O erro da camada inferior só ganhava sentido topológico após uma regra do participante.

A lista de partida não era um retrato completo

Um sistema recém-iniciado precisava conhecer alguns interlocutores antes de aprender outros. IANA manteria core.EON e core.EON-UDP com as SNPAs lógicas de um salto para cada modalidade. Havia ainda hosts.EON e hosts.EON-UDP, destinados a aplicações e pessoas. Esses dois últimos não eram usados pelo OSI CLNL.

Uma linha em core.EON não declarava a função do host. A entrada podia pertencer a um ES, um IS ou uma combinação. Um participante central podia começar a funcionar antes de sua inclusão, porém os demais, ao reiniciar, não saberiam enviar-lhe mensagens de configuração. O arquivo respondia “com quem começar”, não “quem roteia agora”. O arquivo hosts respondia apenas “quem participa”, em um sentido de consulta, sem alimentar a camada de rede.

O exemplo imaginário de Fordor explora a defasagem. 192.5.2.1 atuava como IS e integrava o núcleo; 192.5.2.2 era ES. Os dois trocavam de função mantendo endereço e conectividade. Se o arquivo de IANA continuasse antigo, os demais sistemas enviariam configuração a .1, que passaria a responder como ES, e não saberiam iniciar contato com o novo IS .2. A segunda máquina seria visível para IP e invisível como o intermediário esperado pelo EON.

Quando .2 fosse inicializada, seus próprios anúncios OSI alcançariam outros intermediários, que responderiam e atualizariam o cache. A topologia lógica se recomporia por aprendizado. O episódio hipotético não descreve uma falha de Internet; descreve o intervalo entre uma mudança de papel e a circulação de evidência suficiente sobre ela.

A porta 147 atendia outro conjunto de implementadores

Nem todo sistema dava acesso direto à camada IP. Para quem conseguia usar UDP, EON-UDP carregava o NPDU na porta 147 e posicionava SNAcP acima de UDP. As demais convenções eram parecidas, mas os dois grupos não se comunicavam diretamente. Uma ponte poderia ser concebida, porém não foi especificada. Os quatro arquivos separados acompanhavam essa divisão entre duas experiências paralelas.

O contraste com outros RFCs também depende da altura da pilha. RFC 1006 oferecia serviço de transporte OSI sobre TCP para a sessão e camadas superiores. RFC 1070 punha rede e transporte OSI sobre o internetwork IP. RFC 1069 fazia uma passarela CLNP aproveitar roteamento e endereçamento da Internet; EON queria que a passarela encaminhasse segundo roteamento e endereçamento OSI.

Fontes e limites

RFC 1070 registra uma proposta, um conjunto de acordos e uma topologia fictícia. Não demonstra adoção ampla, operação em produção ou genealogia direta com redes sobrepostas atuais. RFC 994 e RFC 995 documentam CLNP e ES-IS no período, mas não certificam a implementação de um participante. Fordor não foi um incidente real.

O achado histórico é a separação de autoridades. A Internet podia entregar o invólucro sem conhecer a associação que existia dentro dele. Lista, cache, configuração e troca de rotas continuavam responsáveis por fatos que o simples alcance IP não continha.