Кратко

  • Demand RIP заменял периодическую рассылку по X.25 и ISDN подтверждаемыми обновлениями по событию. Простой канал можно было закрыть, а маршруты из таких ответов обычно становились постоянными и не старели лишь из-за молчания.
  • Неудачная реальная попытка установить соединение позволяла диспетчеру канала сообщить о недоступности следующего узла; тогда начинались старение, hold-down и удаление. ACK доказывал получение обновления, но не истинность маршрута и не успех пользовательского трафика.
  • RFC 1581 сообщал об одной завершённой реализации, испытанной против самой себя на двух типах WAN. RFC 1264 отделял этот результат от совместимости независимых реализаций разных производителей.

Регулярная проверка не давала вызову закончиться

RFC 1582 был парной спецификацией Demand RIP категории Standards Track, датированной февралём 1994 года в официальной карточке. Он исходил из свойств сетей с установлением соединения. Виртуальный канал открывался при появлении данных и освобождался после окончания активности. Пользовательские сеансы могли быть короткими и редкими.

Обычный RIP всё равно повторял сведения через равные интервалы. На LAN широковещательная посылка уходила в общую среду. На WAN без вещания она превращалась в отдельные сообщения каждому известному адресу. Документ оценивал одну волну для N маршрутизаторов как N × (N - 1) обновлений по N × (N - 1) / 2 соединениям. Одновременных каналов могло быть меньше, чем соседей: базовый интерфейс ISDN в примере поддерживал два вызова.

Более редкая рассылка уменьшала плату, но замедляла реакцию. Обычный период сохранял отзывчивость ценой занятых вызовов и очередей. Demand RIP изменил не столько интервал, сколько основание отправки: запрос, изменение базы или переход следующего узла из down в up по сообщению диспетчера.

Молчание больше не стирало принятое утверждение

Сопроводительный RFC 1581 — анализ категории Informational, что видно в записи RFC Editor. Он кратко формулировал обмен: на коммутируемых WAN-каналах по требованию нет периодических сообщений; обновление повторяется до подтверждения; полученные сведения в нормальном режиме не истекают. На LAN и фиксированных двухточечных линиях продолжал работать обычный RIP с периодическими обновлениями.

RFC 1582 разделял записи базы на два вида. Маршрут из периодического LAN-ответа был временным и без обновления исчезал. Маршрут из инициированного WAN-ответа обычно был постоянным.

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

Поэтому «давно ничего не слышали» и «попытались соединиться и не смогли» стали разными фактами. Первое было специально созданной тишиной, а не новым положительным измерением. Второе могло запустить отзыв. Право опровергнуть запись перешло от периодического таймера к названным событиям.

Диспетчер канала получил голос в состоянии маршрута

RFC 1582 помещал диспетчер под IP, IPX и процессы маршрутизации. Тот сопоставлял логический адрес следующего узла физическому адресу X.25 или ISDN, открывал виртуальный канал при появлении данных либо обновления и закрывал его по таймеру простоя.

Если в обычной работе соединение не устанавливалось, диспетчер выдавал circuit down. Постоянные записи через этот узел переводились во временные, старели, объявлялись недоступными на протяжении hold-down и затем могли удаляться. Раннее восстановление возвращало им постоянный статус; после истечения требовались запрос и полный обмен базами.

circuit up тоже подтверждал узкое событие. Диспетчер снова связался с соседом по своей процедуре, но не проверил все прежние маршруты. Поэтому базы наполнялись заново. Установленный вызов, запись в RIB, выбор в FIB, прохождение пакета и результат приложения оставались пятью разными квитанциями.

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

ACK закрывал вопрос доставки, а не правды

После отмены следующего периодического цикла единичная потеря изменения становилась опаснее. Виртуальный канал мог быть недоступен, очередь переполнена, вызов вытеснен другим или кадр испорчен. Поэтому RFC 1582 добавил запросы, ответы, подтверждения и повторы.

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

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

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

Сэкономленная линия стала долгом состояния

Постоянная запись не могла исправиться простым забыванием. RFC 1582 требовал хранить все альтернативы либо ограниченный набор с отметкой, что другие были отброшены, и своевременно запрашивать их снова. То, что периодическая рассылка раньше восстанавливала автоматически, теперь оставалось в памяти или возвращалось явной процедурой.

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

RFC 1582 прямо обсуждал разные жизненные циклы компонентов. В описанной реализации диспетчер и маршрутизация были тесно связаны. В Unix первый мог находиться в ядре, второй — в отдельном процессе; в другом изделии диспетчер мог жить на плате. Если они могли погибать независимо, требовались keepalive и повторная синхронизация. Работа одной части не доказывала, что другая хранит состояние того же поколения.

Испытание с самим собой не стало испытанием двух реализаций

RFC 1581 говорил, что была известна одна законченная реализация. Продукт Spider Systems поддерживал IP RIP-1, IPX RIP и IPX SAP, но тогда ещё не RIP-2. Новый режим проверили против самого себя на X.25 и ISDN, а на Ethernet он работал рядом с обычными реализациями. Ещё два Novell-варианта находились в разработке.

Это доказывало существование кода и опыт на двух WAN. Но не доказывало, что независимый второй автор одинаково понял фрагменты, таймеры, перезапуск и сигналы up/down.

RFC 1264 и его официальная запись объясняли требовательность. Протоколы маршрутизации — распределённые алгоритмы реального времени. Работа одной программы в одной среде не гарантирует несколько производителей в другой. Независимые реализации, проверка всех функций и демонстрация механизмов безопасности являлись отдельными свидетельствами.

История становится хуже, если «реализовано» переименовать в «совместимо», но и самопроверку нельзя объявить нулём. Её ценность определяется честно указанным масштабом.

Поздняя версия изменила механизм, но сохранила презумпцию

В январе 1997 года вышел RFC 2091, что подтверждает его карточка. По сравнению с RFC 1582 он после полного обмена посылал только изменения, снижал трафик и память и снимал предел в 255 фрагментов, отказавшись от прежней фрагментации.

Основная ответственность сохранилась. Маршруты из инициированных WAN-ответов оставались обычно постоянными. Диспетчер продолжал выдавать down и up. Запросы и ответы нуждались в подтверждении и повторе. Длительное отсутствие ACK могло сделать следующий узел недоступным. Восстановление и запуск требовали flush и полного обмена.

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

Источники