Кратко

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

У обещания есть таймер очистки

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

Так RFC 2205 определяет soft state. Path и Resv создают и периодически обновляют состояние. Если до срока очистки не приходит подходящее сообщение, запись исчезает. Несколько потерь сигнализации можно пережить, но вчерашний запрос не превращается в бессрочное право на сегодняшние ресурсы.

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

Path идёт с данными, Resv — против них

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

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

Для multicast запросы нескольких получателей могут сливаться. Пересылаемый flowspec может быть локально изменён или представлять объединение ветвей. Простая запись «Resv получен» не сохраняет ни происхождение требования, ни его преобразования.

Две проверки, а затем действие

На каждом узле admission control отвечает, хватает ли ресурсов. Policy control отвечает, имеет ли пользователь право их резервировать. RFC 2205 требует положительного результата обеих проверок.

Лишь затем узел настраивает классификатор и планировщик пакетов либо механизм канального уровня. RSVP переносит параметры качества и политики как непрозрачные данные; их смысл и исполнение остаются за локальными системами.

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

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

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

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

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

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

ResvConf полезен как квитанция сигнализации. Он становится опасным, когда панель делает из него сертификат результата.

Старый маршрут не исправляют — он перестаёт обновляться

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

PathTear и ResvTear могут ускорить удаление, однако надёжная доставка не гарантируется. Потерянный teardown не оставляет постоянного права: таймер всё равно очищает заброшенное состояние.

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

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

Сжатое обновление не отменяет аренду

Полные периодические Path и Resv создают нагрузку. RFC 2961 добавил MESSAGE_ID, подтверждения на уровне перехода для определённых сообщений, объединение и Summary Refresh, который обновляет известное состояние по идентификаторам.

Экономится представление, а не обязательство. Summary Refresh должен сохранять синхронизацию soft state. Если указанное состояние не найдено, сосед может вернуть refresh NACK. ACK подтверждает доставку сигнализации соседу, но не качество услуги по всему пути.

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

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

RFC 2745 определяет DREQ и DREP для сбора Path- или Resv-состояния по узлам RSVP. Ответы помогают найти место, где запись отсутствует или отличается.

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

Диагностика добавляет свидетеля. Она не даёт плоскости управления права говорить за плоскость данных.

Вклад Zhang не требует мифа о единоличном авторстве

IETF Datatracker перечисляет Lixia Zhang среди авторов RFC 2205. Биография UCLA относит замысел и разработку RSVP к её работе в Xerox PARC. Сам RFC указывает Robert Braden редактором, Zhang, Steven Berson, Shai Herzog и Sugih Jamin авторами и признаёт более широкое сотрудничество.

Internet Hall of Fame связывает работу Zhang с RSVP и последующей практикой RSVP-TE. Это институциональная оценка, не подсчёт операторов или трафика. RSVP-TE также нельзя отождествлять с исходным протоколом интегрированных услуг.

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

Семь квитанций вместо одного зелёного знака

Первая описывает путь: отправитель, сеанс, маршрут, предыдущий переход и время. Вторая — запрос: получатель, точный Resv, фильтры, flowspec, просьба о подтверждении и эпоха. Третья — полномочия: admission и policy на каждом существенном узле.

Четвёртая фиксирует установку: цель классификатора и планировщика, результат операции, чтение конфигурации. Пятая — актуальность: интервал, последнее обновление, срок очистки, Summary Refresh и NACK. Шестая ограничивает ResvConf или DREP конкретным узлом, состоянием и временем. Седьмая содержит фактический путь данных и измеренный сервис за период.

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

Источники