Кратко

  • Сокращённое обновление RSVP ссылается на состояние Path или Resv, ранее переданное целиком. Оно продлевает существующее состояние, но не заменяет описание нового или изменённого запроса.
  • Неизвестный идентификатор позволяет запросить недостающую информацию. Найденная запись с повреждённым содержимым может не вызвать такого запроса: RFC 2961 прямо оговаривает это ограничение.
  • Полные обновления время от времени, а затем надёжная доставка и отдельное обнаружение отказа соседства сохраняли функции прежнего повторения. Уменьшение служебного трафика не отменяло обязанности восстанавливать состояние.

Что именно подтвердил сосед

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

Расширения RFC 2961, опубликованные в апреле 2001 года, делали доставку надёжнее при помощи идентификаторов, подтверждений и быстрых повторных передач. Синтаксически неверное сообщение подтверждать не следовало. Но даже корректный ответ не превращался в универсальное свидетельство работоспособности услуги.

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

Повторение поддерживало не только срок жизни

Базовый RSVP из RFC 2205, датированной сентябрём 1997 года, использует состояние, которое требуется периодически обновлять. Сообщения Path и Resv поддерживают его; если обновления долго не поступают, состояние удаляется. Явное завершение может ускорить освобождение, но потеря такого сообщения не должна оставлять резервирование навсегда.

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

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

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

Идентификатор выбирал запись, а не доказывал её правильность

Чтобы применять Srefresh, отправитель прежде должен был объявить состояние полностью вместе с MESSAGE_ID. После этого короткое сообщение могло перечислять идентификаторы ранее переданных Path или Resv. Получатель находил записи и продлевал их без очередной передачи каждого объекта описания.

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

Сам MESSAGE_ID включает идентификатор и эпоху, а область его интерпретации зависит от адреса создателя. Для первоначальных Path и Resv этот адрес задаётся в RSVP_HOP и не обязательно совпадает с внешним IP-адресом источника. Эпоха помогает различать периоды работы, в том числе разделённые перезапуском.

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

Другая оптимизация документа, Bundle, объединяет полные сообщения RSVP в одну дейтаграмму. Она не сливает несколько запросов ресурсов в одно одобренное резервирование. Упаковка, доставка и смысл состояния остаются разными задачами, даже когда их обслуживает одно расширение.

Отсутствие можно было назвать

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

Этот отрицательный ответ не означает отказ выделить полосу пропускания. Он сообщает, что ссылка не сопоставилась с известным состоянием. Поэтому рост числа NACK нельзя автоматически трактовать как недостаток ресурсов, а успешную повторную доставку описания — как принятие запроса всеми узлами пути.

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

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

Ограничение было частью спецификации

Раздел 5.5 RFC 2961 прямо говорит, что Srefresh не сохраняет в точности все свойства восстановления обычных обновлений. Распространённые события вроде потери пакетов и смены маршрута учитываются, однако внутреннее повреждение состояния приводится как пример возможного пробела.

Это не описание подтверждённой аварии у конкретного оператора. Это граница метода. Можно представить запись, у которой идентификатор по-прежнему совпадает, а часть содержимого стала неверной. Её продление не означает, что неверная часть была обнаружена. Отсутствие NACK в такой ситуации не равнозначно положительному заключению о корректности.

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

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

Обнаружить пропущенное извещение об изменении и снова доставить полное описание — не одна операция. Если объединить их в обещание «контрольная сумма проверяет всё состояние соседа», получится утверждение, от которого спецификация как раз воздерживалась. Полная передача возвращает определённую возможность восстановления, а не исключает все ошибки устройства.

Подлинный отправитель не добавлял отсутствующие поля

Отдельная защита целостности RSVP, рассмотренная в RFC 2747, относится к сообщениям и аутентификации соседей при соответствующих предпосылках о ключах. MESSAGE_ID не выполняет эту криптографическую функцию. Защита целостности также не означает шифрование ради сокрытия содержимого.

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

Восстановление после перезапуска, описанное в RFC 5063 в октябре 2007 года для GMPLS RSVP, показывает похожую осторожность. Нижестоящий сосед может перечислить идентификаторы Path, ранее полученных от перезапустившегося вышестоящего контроллера. Это отличается от обычного краткого обновления того, что сам отправитель ранее объявлял.

Узнаваемые ссылки уменьшают объём восстановления; если их недостаточно, RecoveryPath передаёт более полное описание. Но это сообщение само по себе не вправе создавать отсутствующее состояние пересылки. Восстановление связывает сигнализацию с сохранившимся состоянием пересылки, а создание нового требует предусмотренных отдельно процедур, например Path сверху или управляющего указания на входе с соблюдением политики.

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

Уменьшение трафика перераспределяло работу

Анализ масштабирования RSVP-TE в RFC 5439, опубликованной в 2009 году, рассматривает память и обработку отдельных состояний. Длинный список всё равно требует поиска по множеству идентификаторов. Меньшее число пакетов не уничтожает сами резервирования и не задаёт универсальную производительность современных маршрутизаторов.

В мае 2018 года RFC 8370 связала длительные периоды обновления с надёжной доставкой, более коротким обслуживанием ещё не подтверждённых Path и Resv и явным обнаружением отказа сигнального соседства. При его отказе полученные через него состояния должны рассматриваться как просроченные.

Часть работы прежнего периодического обмена тем самым передавалась другому механизму. Просто увеличить число в таймере было недостаточно. Усиленные требования к подтверждениям относятся к реализациям новых методов, а не задним числом ко всем узлам RFC 2961. Для соседа без нужных возможностей сохраняется традиционное поведение.

Реестр параметров RSVP в IANA фиксирует значения сообщений, объектов и признаков возможностей. Он даёт общие обозначения, но не подтверждает включение функции на определённом соединении. Возможности должны проявляться в текущем обмене; исчезнувший признак нельзя заменить воспоминанием о том, что раньше всё работало.

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