Кратко

  • В опыте RFC 1477 остановка шлюза и изменение транзитной политики по отдельности привели к разборке старого пути и созданию альтернативного; наблюдавшийся сеанс Telnet сохранился.
  • Результат относился к урезанному прототипу: политики источника и нескольких шлюзов между доменами в нём не было, сервер сопоставлений заменили локальными таблицами, а численные результаты производительности не опубликовали.

Два переключения на одном кольце

Основной опыт RFC 1477 проводился на кольце из четырёх административных доменов. В S находился исходный хост, в D — конечный. Транзитные T1 и T2 давали два пути между ними. Когда пользователь открывал Telnet, агент пути в S запрашивал у сервера маршрутов policy route и устанавливал путь.

Сначала исследователи останавливали процессы IDPR на шлюзе действующего пути через T1. Соседние шлюзы замечали потерю связи, распространяли новые сведения и разбирали оставшиеся участки старого пути. Агент в S запрашивал новый маршрут, сервер выбирал T2, после чего создавался заменяющий путь. В документе сказано, что сеанс Telnet оставался цел.

После восстановления T1 меняли уже не процесс, а правило. Политику T2 перенастраивали так, чтобы она запрещала трафик из S в D. Новая политика распространялась, путь через T2 становился недопустимым и разбирался, а трафик возвращался через T1. Сеанс снова не прервался.

Наблюдение не сводилось к одному окну терминала. В прототипе имелась подробная инструментализация: изменения смежности и транзитных правил, обмен link-state-информацией, сгенерированные маршруты, управляющие сообщения, установка и снятие пути были видны отдельно. Причину и реакцию можно было связать по внутренним событиям.

При этом RFC не даёт числа потерянных пакетов, распределения времени сходимости и количества повторов. Сохранность относится к описанному сеансу и двум описанным изменениям. Она не обещает того же для любого приложения и масштаба.

Ради работающей версии вычеркнули два случая

Авторы прямо пишут: прототип охватывал большую часть функций IDPR, но не все. Чтобы быстрее получить работающее программное обеспечение, они намеренно отказались от поддержки политики источника и нескольких policy gateways, соединяющих два домена.

Политика источника не является копией транзитной. Транзитный администратор определяет условия использования своих ресурсов. Источник задаёт требования к услугам и предпочтения для собственного трафика. Эксперимент менял правило T2 и проверял первую поверхность. Вторая отсутствовала в коде.

Два направления вокруг кольца также не заменяют несколько шлюзов на одной границе. В последнем случае возникают локальный выбор, согласование состояния, резервирование и частичный ремонт. Переключение T1—T2 не исполняло исключённую ветвь.

Такое сужение было разумной инженерной мерой. Маленькое исполняемое ядро быстрее сталкивается с реальностью. Но успех ядра нельзя по общему имени перенести на удалённые части архитектуры.

Настоящие машины не отменяли простоту задачи

Разработка началась летом 1990 года, а эксперименты с завершённым прототипом — в феврале 1991-го. USC использовал SPARC1+ в перестраиваемой лабораторной Ethernet-сети. SAIC соединял Sun3 в Sparta и MITRE через Alternet по SLIP со скоростью 9,6 кбит/с и по X.25 через полигон DCA EDN. BBN связывал SPARC1+ в BBN и ISI сетями DARTnet и TWBnet.

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

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

Фиксированная подстановка закрывает зависимость для конкретного теста. Она не создаёт журнал выполнения заменённой зависимости.

Всё основное — в пределах какого объекта

RFC 1477 называет опыты простыми, а затем говорит, что они проверили все основные функции прототипа. Формулировки совместимы. Программа следила за связностью, распространяла сведения, строила маршрут, устанавливала путь, замечала отказ, удаляла старое состояние и создавала замену. Она реагировала и на недопустимую транзитную политику.

Но речь идёт именно о прототипе. Архитектура RFC 1478 и протокол RFC 1479 шире. Наличие требования в спецификации не превращается в выполненный тест в версии, где это требование исключено.

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

Производительность без опубликованных чисел

Участники USC и SAIC измеряли вычисления при установке пути и пересылке сообщений. Они сравнивали IDPR с IP-инкапсуляцией и обычную IP-пересылку, а также режим без значения целостности/аутентификации и RSA/MD4.

Измерения названы обнадёживающими, но таблиц в RFC нет. Даны контакты для получения данных и предупреждение: значения нельзя бездумно переносить на другие реализации, поскольку оптимизации уделили мало времени.

Источником подтверждены факт измерения, предмет сравнения, оценка авторов и ограничение. Задержку, пропускную способность и нагрузку на процессор из слова «обнадёживающие» вывести нельзя.

gated создал возможность следующего шага

В 1992 году SRI присоединился к SAIC и BBN, чтобы встроить IDPR в UNIX-процесс gated. RFC 1477 утверждает, что эта версия содержала полную функциональность IDPR, имела интерфейс настройки и благодаря одному процессу работала эффективнее многопроцессного прототипа. Она была свободно доступна для экспериментов на UNIX без самостоятельной разработки.

Доступность снижает цену входа, но не считает установки. Следующей целью было получить опыт в операционных сетях с реальными ограничениями и требованиями трафика. На момент публикации в выбранных местах шли пилот и демонстрация.

Доступно, установлено, включено, реально несёт трафик, устойчиво эксплуатируется и широко принято — разные состояния. Начавшийся пилот не является отчётом о завершении.

Название документа тоже не закрывает вопрос. Карточка RFC 1477 относит его к Informational, несмотря на слова Proposed Standard в заголовке. Карточки RFC 1478 и RFC 1479 фиксируют состояние документов архитектуры и протокола. RFC 2026 объясняет стандартный процесс. Статус текста не сообщает, какой процесс загружен на шлюзе.

Не стирать границу успеха

RFC 1102 обсуждал построение policy route, а RFC 1104 разделял распространение маршрутов, обработку пакетов, выделение ресурсов и учёт. Особенность RFC 1477 в другом: он оставил читаемый переход от архитектуры к ограниченному исполняемому артефакту и наблюдаемому опыту.

Тексты Heng Lu о приоритете работающего кода, минимальной начальной спецификации и добровольном принятии и слоях реальности дают правило: выполнение сильнее намерения, но не может свидетельствовать за отсутствующий код.

Сохранить перечень исключений — не значит принизить эксперимент. Именно граница делает достоверным то, что осталось внутри: два изменения, два новых пути и один сохранившийся сеанс.

Источники