Кратко

  • TUBA предлагала сохранить TCP, UDP и многие интернет-приложения, заменив IPv4 на CLNP и структурированные адреса NSAP.
  • Для перехода требовалось больше, чем поддержка на маршрутизаторах: важны были хосты, DNS, приложения со встроенными IPv4-адресами, агрегация маршрутов и полномочия по изменению CLNP.

Что TUBA сохраняла и что заменяла

В июне 1992 года Росс Каллон опубликовал RFC 1347 с предложением TUBA — «TCP and UDP with Bigger Addresses». В документе были связаны две проблемы: адресного пространства IPv4 длиной 32 бита становилось недостаточно, а объём маршрутной информации в магистральных сетях быстро рос. Предлагалось не расширять поле IPv4, а сменить сетевой протокол: запускать TCP или UDP поверх CLNP — протокола без установления соединения из архитектуры ISO — и использовать адреса NSAP вместо IP-адресов.

Обещание совместимости было ограниченным, но практичным. Браузер, почтовая программа или приложение для передачи файлов могли продолжить работу через привычный TCP или UDP, если их собственный протокол не опирался на 32-битные адреса. Однако сетевой уровень ниже изменился бы: формат пакетов, адресация и пересылка стали бы другими. Каллон указывал, что CLNP уже предоставлял сервис дейтаграмм и применялся в некоторых региональных и магистральных сетях Интернета. Использование готовой технологии могло сократить работу по созданию и развёртыванию ещё одного сетевого протокола.

TUBA не требовала полного перехода Интернета на OSI. Идея заключалась в замене IP при сохранении TCP, UDP и многих привычных приложений. Экспериментальный документ RFC 1561, опубликованный в декабре 1993 года, описал профиль CLNP для такой среды. В нём отмечалось, что IP и CLNP предоставляют похожие, но не идентичные услуги; нужно было сохранить смысл информации, на который рассчитывали интернет-протоколы.

В выборе пути участвовали DNS и конечные хосты

RFC 1347 описывал постепенное сосуществование старых и обновлённых хостов. Если DNS возвращал обновлённому хосту обычный IP-адрес старого узла, тот использовал прежний стек. Если возвращался более длинный NSAP-адрес узла с поддержкой TUBA, TCP или UDP передавался через CLNP. DNS требовалась новая запись «long-address». Маршрутизаторы должны были отдельно пересылать IP и CLNP — на многопротокольных устройствах или в разных группах. Протокол выбирался по адресу, полученному из DNS; массовый перевод или туннелирование каждого пакета между IP и CLNP не предусматривались в основном варианте.

Постепенное внедрение не снимало взаимозависимость. Обновлённый хост мог оставаться в сети без CLNP. Некоторые варианты использования FTP и NFS передавали IP-адреса внутри данных приложения, поэтому одного сохранения TCP было недостаточно. Производителям хостов, операторам DNS и сетевым операторам пришлось бы координировать переход. Более длинный адрес также не гарантировал компактную таблицу маршрутизации: распределение NSAP должно было учитывать топологию, чтобы поддерживалась агрегация маршрутов.

Один довод в пользу TUBA опирался на наличие маршрутизаторов с поддержкой CLNP. В RFC 1752, опубликованном в январе 1995 года, обзор отделял такую способность от готовности всей сети. Рецензенты отмечали заметное распространение CLNP-совместимых маршрутизаторов, но меньше соглашались с тем, что CLNP широко работал на хостах и в реальных сетях. Устройство, которое умеет пересылать пакет, полезно, но это ещё не доказательство связи между приложениями от одного края до другого.

У заимствованного протокола был владелец стандарта

RFC 1752 фиксирует вопросы к выравниванию полей заголовка CLNP, маршрутизации от источника, сообщениям об ошибках и агрегации адресов NSAP. Некоторые проблемы могли потребовать изменений самого CLNP или его профиля. Сообщество TUBA расходилось во мнении, кто вправе их вносить: мог ли IETF менять базовые спецификации CLNP или требовалась процедура ISO? От ответа зависели скорость исправлений и ответственность за поддержку сетевого уровня, на который собирались опереться интернет-операторы.

Рекомендация IPng не обнулила вклад TUBA. После обсуждения нескольких предложений RFC 1752 рекомендовала обновлённый SIPP в качестве основы IPng. В документе говорится и о синтезе: SIPP дал большую часть базового протокола, а TUBA повлияла на автонастройку и переходные механизмы. CLNP не стал новым сетевым уровнем Интернета, но TUBA не была идеей, которая ничего не оставила после себя.

Поздняя Note:64 Хэн Лу полезна как ретроспективная аналитическая рамка, а не свидетельство о событиях 1990-х: какие общие правила нужны для взаимодействия, какие решения можно оставить разработчикам и чем подтверждается внедрение? История TUBA показывает, что повторное использование протокола может уменьшить объём новой разработки, но не отвечает на вопросы о его сопровождении, реализации на конечных хостах и фактической передаче трафика сетями.

Источники