Кратко

  • RFC 1070 помещала полные PDU сетевого уровня OSI в IP-дейтаграммы. Это давало разработчикам большую среду для проверки маршрутизации OSI без установки незрелых протоколов в существующие шлюзы Интернета.
  • EON создавала собственный логический слой через адреса NSAP, SNAcP, начальные списки, локальные кэши и роли ES/IS. IP-доступность не доказывала одношаговое соседство, текущую роль, членство в кэше или наличие изученного маршрута.

В феврале 1989 года авторы RFC 1070 сразу обозначили предел: методы годились только для ограниченного эксперимента, а не для рабочей среды. Протоколы сетевого уровня OSI находились на разных стадиях зрелости. Им требовались испытания в большой, разнообразной и меняющейся топологии, но внедрение этих реализаций во множество действующих IP-шлюзов могло нарушить сеть, которая уже приносила пользу.

Предложение использовало связность, не меняя шлюзы. Полный пакет CLNP, ES-IS или IS-IS становился данными IP-дейтаграммы. На локальных линиях реализация могла запускать OSI непосредственно; при переходе через IP-шлюз она считала Интернет одной нижележащей подсетью. Эту экспериментальную конструкцию назвали EON — Experimental OSI-based Network.

Внешний адрес не назначал внутреннюю роль

Прямой вариант EON использовал значение 80 в поле Protocol IP. Фрагментацию старались поручить OSI CLNL, поскольку её поведение тоже проверялось. Однако IP мог фрагментировать оболочку по дороге, поэтому получатель должен был уметь собирать и нижний уровень.

Доставка фрагмента, сборка дейтаграммы, обработка ISO-gram, принятие группового назначения и появление маршрута были разными событиями. RFC 1070 предполагала, что на площадке множество машин может быть доступно по IP, но только выбранная часть объявит себя непосредственно подключённой к IP subnet в смысле EON.

Формат NSAP опирался на RFC 1069 и включал четыре октета Internet-адреса перед селектором. Благодаря этому SNPA нижней подсети выводилась алгоритмически. IANA назначала номер домена маршрутизации, а локальная область сначала была нулевой.

Такой расчёт указывал, куда послать IP-пакет. Он не сообщал, работает ли система как ES, IS или в обеих ролях. Участник мог поменять роль и логическое отношение к подсети, не меняя физическую доступность. Документ специально исключал маршрутизацию ISO-grams алгоритмами IP, промышленный масштаб и шлюзование IP-CLNP. Проверять следовало именно адресацию и маршрутизацию OSI.

Общий канал возникал из множества индивидуальных копий

ES-IS и IS-IS предполагали групповые адреса для всех конечных и всех промежуточных систем на широковещательной подсети. IP subnet не предоставляла эксперименту эту семантику. Между OSI CLNL и IP появился небольшой SubNetwork Access Protocol — SNAcP.

Локальный SNAcP хранил таблицу Internet-адресов, которые считал достижимыми за один переход ISO 8473. Обычному адресату предназначалась одна копия. Для всех ES, всех IS или broadcast ISO-gram размножался по каждой SNPA из кэша. Заголовок версии 1 обозначал смысл адреса и содержал контрольную сумму Fletcher.

При приёме индивидуальные и широковещательные сообщения принимались, а all-ES и all-IS зависели от локальной настройки роли. Поэтому отправитель определял аудиторию своим кэшем, а получатель — своей конфигурацией. Успешная передача внешнего пакета не доказывала полноту таблицы или согласованность представлений всех участников.

Сигналы ICMP превращались в состояние EON только через местное правило. Destination unreachable, parameter problem и time exceeded могли сделать запись непригодной; source quench — временно непригодной. Уведомление управления могло означать сообщение на консоли, запись в журнал, счётчик, локальный процесс или бездействие. При репликации SNAcP пропускал непригодный адрес, а при индивидуальной отправке возвращал ошибку OSI CLNL.

Список запуска и справочник выполняли разные функции

Новой системе нужны первые собеседники прежде, чем протокол обмена научит её остальным. IANA должна была поддерживать core.EON для прямого IP-варианта и core.EON-UDP для UDP. Там перечислялись SNPAs, логически расположенные в одном переходе от других core systems.

Отдельные hosts.EON и hosts.EON-UDP помогали приложениям и людям находить конечные системы. OSI CLNL их не использовал. Даже запись в core-файле не назначала маршрутизатор: система могла быть ES, IS либо сочетать роли. Новый core-участник мог работать до публикации адреса, однако peers со старым стартовым файлом не знали, что ему следует послать ESH или ISH.

Гипотетическая площадка Fordor показывает, как записи расходились без физической аварии. Сначала 192.5.2.1 выступала как IS и core system, а 192.5.2.2 — как ES. Машины менялись ролями, сохраняя Internet-связь. Пока файл IANA оставался старым, другие участники продолжали направлять конфигурацию .1 и получали ответ уже от ES. О новом IS .2 они не знали, поэтому в EON он казался недоступным.

Когда .2 запускалась и сама рассылала конфигурационные сообщения OSI, другие IS отвечали и обновляли кэши. Так устанавливались логические связи. IP-путь всё это время существовал; отсутствовало актуальное знание, которое связывало новую роль с топологией эксперимента.

EON-UDP не была прозрачной заменой EON

Некоторые реализации имели доступ к UDP, но не к IP напрямую. EON-UDP помещала NPDU в порт 147 и ставила SNAcP между UDP и ISO 8473. Остальная логика была похожа, однако прямой совместимости с EON не было. Возможный шлюз оставался вне описания. Раздельные core- и hosts-файлы обслуживали два параллельных эксперимента для разных возможностей систем.

Соседние документы решали задачи на другой высоте. RFC 1006 предоставляла транспортную службу OSI поверх TCP для сеансового и более высоких уровней. RFC 1070 переносила сетевой и транспортный уровни OSI через IP-интерсеть. RFC 1069 использовала Internet-маршрутизацию и адресацию в шлюзе CLNP; EON сохраняла для этого маршрутизацию и адресацию OSI.

Источники и пределы

RFC 1070 фиксирует экспериментальное предложение, а Fordor — вымышленный пример. Документ не подтверждает широкое внедрение, эксплуатационную пригодность или прямое происхождение современных overlay-сетей. RFC 994 и RFC 995 дают спецификации CLNP и ES-IS того времени, но не доказывают правильность конкретной реализации EON.

Историческая граница состоит в другом. Сеть-переносчик может знать, как доставить оболочку, и не знать, кто считается участником внутри неё. Для адреса, начальной записи, локального кэша, роли и изученного маршрута нужны разные свидетельства.