Кратко

  • Plutarch не требовала заменить существующий интернет. Глобальный IPv4 мог работать без изменений как один контекст, рядом с которым постепенно появлялись другие режимы связи.
  • Имя и адрес имели значение внутри context. При переходе interstitial function должна была заново связать значение и перевести различия в адресации, именовании, маршрутизации и транспорте.
  • Работа была архитектурным началом, а не отчётом о готовой системе. Безопасность, аудит, управление полномочиями, масштабируемый поиск, сообщения об отказах и политика выбора цепочки оставались открытыми.

Неоднородность перестала считаться дефектом края

Узкая однородная середина дала интернету важное преимущество. Приложения не обязаны знать технологию каждого канала, а физические сети — понимать каждое приложение. Общая модель датаграммы и адреса снизила стоимость совместимости.

Авторы Plutarch начинали не с отрицания этого достижения. Они связывали рост интернета с хорошо определённым стеком, простотой и умеренностью функций внутри сети. Их тревожило другое: успешная модель стала единственной рамкой, в которую пытались поместить сенсоры, мобильные сети, overlays и частные технологии.

Plutarch признала каждый такой режим context. Глобальный IPv4-интернет оставался самым крупным из них, но не обязан был определять внутренние имена, маршруты и транспорт соседей. Он мог быть транзитом, не превращая отличия в ошибку.

Сеть без IP переставала выглядеть неполной периферией «настоящего» центра. Архитектурная обязанность переходила к границе, которая соединяла равноправные режимы.

Контекст ограничивал область значения

В статье context — это область, однородная в существенном отношении, и набор bindings, внутри которого разрешаются имена. Общими могли быть адресный формат, пакет, transport, служба имён, канал или административные правила.

Один endpoint мог одновременно находиться в нескольких контекстах. Членство менялось. Контексты могли быть раздельными, одинаковыми или вложенными: локальный Ethernet внутри IP LAN, а тот — внутри интернета. Единого глобального root context не предполагалось.

Поэтому адрес не переносил свою власть автоматически. Внутри исходного context он указывал на объект. На другой стороне требовалось новое связывание референта.

Rebinding — это проверяемое решение. Кто утверждает соответствие двух имён? Как долго оно действует? Не спрятаны ли за одним локальным значением несколько внешних участников? Plutarch поместила эти вопросы в механизм, а не в примечание оператора.

Interstitial function отвечала за преобразование

Граничный механизм авторы назвали interstitial function, IF. Логически у него был интерфейс к каждому из двух context и внутренняя функция, переводящая данные и свойства. Несколько IF образовывали context chain.

Среди существующих аналогов назывались NAT, сигнальные шлюзы и BGP-роутеры. Более широкие примеры включали соединение разных транспортов, перекодирование видео и добавление прямой коррекции ошибок. IF могла менять представление, состояние, время и гарантию.

Работа распадалась на четыре вида. Адресация требовала управляемых отображений. Naming — разрешения между множеством пространств имён. Routing — осмысленного перехода между, например, беспроводной сетью по требованию и доменом OSPF/BGP, где изменения трактуются по-разному. Transport — решения, где применима оптимизация конкретной технологии.

Граничный receipt должен был бы назвать вход, выход, правило эквивалентности, право конфигурации, удерживаемое состояние и утраченные свойства. Сам факт доставки подтверждает лишь существование какого-то преобразования.

Цепочка давала выбор, но могла спрятать посредника

Последовательность context и IF можно было снова представить как один context. Простому приложению хватало ответа, достижим ли партнёр. Более требовательное могло получить несколько цепочек, сравнить свойства и выбрать.

Так часть решения возвращалась endpoint. Однако абстракция уменьшала видимость. Автоматический repair мог после отказа выбрать цепочку под другой администрацией. Proxy мог завершить соединение и создать новое. Transcoder мог сохранить понятность и снизить качество.

Статья предполагала распределённые службы регистрации, поиска и построения цепочек, причём под несколькими администрациями. Запросы могли предъявлять capabilities. Но выпуск и управление этими полномочиями архитектура не определяла.

Отсутствие единого корня не означало отсутствия власти. Власть могла сосредоточиться в каталоге, ранжировании цепочек, выдаче capability или единственном работающем IF.

Постепенное внедрение меняло порядок согласия

Plutarch подчёркивала две практические особенности: существующий интернет не нужно менять, а новые context можно вводить по одному. Они могли работать поверх него, рядом с ним, под ним или на границе.

Это устраняло всемирный день переключения. Небольшой оператор мог создать локальный режим и переводчик, показать работающий результат, а участники — присоединиться позже. Принятие следовало за реализацией, а не за декларацией.

Но постепенное начало не гарантировало лёгкого конца. Временный IF мог накопить bindings, исключения и состояние. Чем больше приложений полагалось на его особенности, тем дороже была замена. Мост, созданный для отказа от глобальной миграции, мог потребовать одновременной миграции обоих берегов.

Добровольность сохранялась лишь там, где договор перевода был опубликован, состояние переносилось, а альтернативный IF действительно запускался.

Незавершённость была частью честного результата

Авторы ограничили задачу inter-networking. Они не решали распределение ресурсов, своевременность, гарантии, безопасность или аудит. Интерфейсы были strawman, показателей производительности не было, управление capabilities не задавалось.

В будущем оставались масштабируемая маршрутизация между контекстами, обнаружение IF, уведомление об отказах, политика выбора цепочек, API, адаптация transport и масштабируемый поиск имён. Ожидание небольшого числа типов context и коротких цепочек не было результатом наблюдения за production.

Поэтому Plutarch нельзя описывать как развёрнутый и доказанный преемник интернета. Она дала язык для явной неоднородности и показала, где понадобятся дальнейшие receipts. Сделать переводчик видимым — не то же самое, что объявить его надёжным.

Crowcroft — первый в заголовке, но не единственный автор

University of Cambridge называет Jon Crowcroft Marconi Professor of Communications Systems и отмечает более сорока лет работы с интернет-технологиями. Сочетание сетей и распределённых систем объясняет интерес к context, binding и композиции.

Тем не менее Plutarch подписана Crowcroft, Hand, Mortier, Roscoe и Warfield. За ней также стоят более ранние идеи context-relative naming, late binding и end-to-end design. Нельзя делать Crowcroft единственным изобретателем сетевого плюрализма или объявлять любой поздний gateway прямым наследником этой статьи.

Коллективный вклад точнее: неоднородность стала фактом, который архитектура обязана объяснить, а не шумом, который можно стереть с диаграммы.

Источники