Кратко

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

Найденный путь ещё не был полученным ресурсом

Маршрутизация best effort в основном отвечала на вопрос, как достичь адресата по предпочтительной метрике. Требование качества добавляло расходуемые величины. Потоку могла понадобиться остаточная полоса, ограничение задержки или сочетание условий. Кратчайший путь оказывался занят, а более длинный — пригоден.

RFC 2386 назвал QoS-маршрутизацией выбор пути с учётом доступности ресурсов и требований потока. Формулировка была осторожной: найденный путь имел хорошие шансы вместить запрос. Расчёт не создавал ресурс. RSVP мог запросить и зарезервировать его вдоль пути, но не находил автоматически путь с нужной ёмкостью. Маршрутизация предлагала, резервирование закрепляло — это были разные полномочия.

Между ними располагалась цепочка доказательств. Канал измерял локальное состояние. Протокол кодировал, распространял и агрегировал его. Получатель считал по картине, которая могла устареть или потерять детали. Во время установки каждый узел проверял текущую локальную ёмкость. Политика верхнего уровня могла отказать по причинам справедливости, цены или приоритета даже при положительных локальных проверках. Затем следовали выделение, согласованная пересылка и измерение результата.

Карта подсказывала место попытки. Она не подтверждала допуск.

Потребление изменяло сам показатель

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

У свежести была цена. Частые объявления тратили полосу и процессор маршрутизатора. Редкие оставляли старые данные. Грубое квантование снижало объём обновлений, но скрывало различия, важные для допуска. Сглаживание убирало шум и могло убрать краткую, но реальную перегрузку.

Поэтому порог обновления был частью устойчивости. Документ также определил закрепление маршрута: принятый поток некоторое время оставался на выбранном пути и не следовал за каждым колебанием карты. Закрепление не обещало вечности. Оно отделяло непрерывность принятого решения от постоянного обновления окружающего состояния.

Чем точнее решение, тем больше состояние, которое можно потерять

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

Если один маршрутизатор терял запись потока и возвращался к обычной таблице назначения, а предыдущий продолжал вести пакет по особому пути, возникал цикл. Два узла исполняли разные версии реальности.

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

Агрегация покупала масштаб ценой неопределённости

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

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

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

Архитектура оставалась честной, потому что кандидат мог не пройти. Сводка сужала поиск, локальная проверка встречалась с настоящим ресурсом, отказ сохранял законность.

Два темпа автономии

RFC не навязывал единственный внутренний алгоритм. В автономной системе могли развиваться link-state, пробы, статически подготовленные пути и расчёт по запросу. Между системами взаимодействие должно было быть простым, единообразным и устойчивым.

Мгновенное междоменное состояние плохо масштабировалось бы, раскрывало внутренние данные и передавало удалённым вычислителям неизбежно агрегированную картину. Вместо этого предлагались сведения о спроектированной топологии и ёмкости. Отказ или сосредоточенная перегрузка могли вызвать обновление; приход каждого потока в пределах расчётной нагрузки — нет.

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

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

Цена показала отсутствие последней квитанции

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

Объявление фиксировало способность, резервирование — выделение. Ни одно само по себе не измеряло сквозные задержку, джиттер, потери и пропускную способность. Цена обещания могла появиться раньше доказательства исполнения.

Раздел безопасности показывал обратную сторону. Запрос QoS не мог сам себя уполномочить. Произвольные требования истощали ресурсы и лишали обслуживания законные потоки. Проверка, политика, тарификация и policing ограничивали право связать дефицитную ёмкость.

Позднейшие механизмы сохранили разделение труда

RFC 2205 определил сигнальное резервирование RSVP. RFC 2210, 2211 и 2212 связали его с Integrated Services, controlled-load и guaranteed service. RFC 2676 описал механизмы QoS-маршрутизации и расширения OSPF. RFC 3272 поместил расчёт в цикл измерения, моделирования, управления и оценки, а RFC 3630 определил дополнительные атрибуты каналов OSPF.

Эти документы не доказывают повсеместное внедрение рамки 1998 года. Они показывают устойчивость функциональных границ. Объявление питает расчёт. Расчёт предлагает. Сигнализация запрашивает. Допуск решает. Резервирование меняет состояние. Измерение оценивает результат.

RFC 2386 свёл адаптивную маршрутизацию к сбору состояния и вычислению путей. Его историческая ценность — в границах вокруг этих действий. У состояния есть возраст, у объявления — область действия, вычисление даёт кандидата, допуск сверяется с настоящим, резервирование меняет ресурс, а работающий трафик даёт итог.

Там, где карта теряла власть, маршрут должен был получить отдельное разрешение.

Источники