Кратко

  • В проекте Cronus интерфейс виртуальной локальной сети отделял IP от физической сети, чтобы последнюю можно было заменить без переписывания программ сверху.
  • За такую свободу отвечали вполне материальные механизмы: индивидуальные и групповые адреса, шлюзы, таблицы соответствия физическим адресам и ограниченные обещания о доставке.

Если локальная сеть обходится слишком дорого, плохо работает или не выдерживает условий площадки, её хочется заменить. Но вместе с ней легко обнаружить десятки программ, которые знали каждый каприз старой среды. Уильям Макгрегор и Дэниел Тэппан предложили в RFC 824 для Cronus другую расстановку обязанностей. Программы обращались бы к Virtual Local Network — VLN. А её реализация уже разбиралась бы с физической сетью. Для IP лицо собеседника оставалось прежним, даже когда проводка переезжала.

Документ датирован августом 1982 года и относится к распределённой операционной системе, которую проектировала Bolt Beranek and Newman. На схеме TCP и UDP расположены над IP, IP над VLN, а VLN над физической локальной сетью. Авторы сформулировали две цели: совместимость с IP системы DARPA и возможность заменить одну физическую сеть другой при сохранении поведения интерфейса. Смысл слова «виртуальная» находился именно в этом постоянстве для клиента, а не в отсутствии настоящих проводов.

Причины для замены были земными: цена, производительность, механическая и электрическая прочность. Представление операций в коде могло различаться на разных машинах, но функциональные возможности должны были совпадать. При переходе на другую физическую сеть VLN пришлось бы реализовать заново на каждом узле Cronus. Работы меньше от этого не становилось; просто её не размазывали по всему программному стеку. Вместо массового переучивания приложений появлялась одна хорошо определённая граница.

Авторы особо требовали, чтобы IP работал поверх VLN без изменений и расширений. Узлы одного кластера разделяли общую физическую локальную сеть. Сообщения наружу VLN направляла через интернет-шлюз, входящие передавала нужному узлу. С точки зрения Интернета сама VLN считалась сетью с собственным номером. У физической сети номер мог совпадать с ним либо отличаться. Стабильное имя наверху не отменяло необходимости выбрать правильный выход внизу.

Адресация превращала абстрактный замысел в договор с точными условиями. Клиент мог указать один узел, все узлы или группу multicast. В таблице RFC локальные значения от 0 до 1 023 отданы отдельным узлам, от 1 024 до 65 534 — группам, 65 535 — широковещательной рассылке. Для размещения всего диапазона авторы рекомендовали сеть класса A или B. Это числа исторического проекта Cronus. Важна была обязанность сохранить три способа доставки при любой выбранной снизу технологии.

Пример реализации на Ethernet показывает цену такого обещания. Каждый узел хранил VPMap — соответствие между конкретным 32-битным адресом VLN и 48-битным адресом Ethernet. Если физический адрес машины изменился, а адрес VLN остался, сохранённые у соседей соответствия становились неверными. Документ обсуждал сброс интерфейса для восстановления динамических таблиц. Верхние программы могли не заметить переезда; местный почтальон обязан был переписать адресную книгу. Иначе письмо отправлялось по старому адресу с безупречной вежливостью.

Обещания по пакетам имели границы. Дейтаграмму размером до 576 октетов можно было передать между любой парой клиентов VLN; более крупные могли проходить между некоторыми парами. VLN не занималась фрагментацией и сборкой IP-дейтаграмм и не обрабатывала IP-опции. Она не гарантировала доставку каждого пакета и не посылала отрицательных подтверждений за повреждённые или отброшенные. Зато дошедшая дейтаграмма должна была точно передавать отправленную, а каждый предполагаемый адресат получал её один раз либо вовсе не получал. Внутри кластера принятые сообщения сохраняли порядок отправки, хотя отдельные сообщения могли отсутствовать.

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