Кратко

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

Решение выглядело экономным. RSVP поддерживал резервации периодическими сообщениями PATH и RESV. ATM переносил пакеты по виртуальным каналам с контрактами трафика. Если управляющее сообщение шло по VC соответствующих данных, не требовалось строить ещё один канал и ждать его настройки.

Расчёт менялся, когда данные выходили за условия контракта. Механизм отбрасывания несоответствующего трафика мог удалить и сообщение RSVP. Протокол переносил отдельные потери. Продолжительная серия могла исчерпать время soft state, привести к разборке QoS VC и запустить его установление заново. Способ сэкономить сигнализацию создавал дополнительный цикл сигнализации.

Для soft state важен своевременный приём

RFC 2205 сделал состояние RSVP временным намеренно. PATH и RESV создавали и обновляли его; без совпадающего обновления до cleanup timeout запись удалялась. Старые резервации исчезали вслед за изменением маршрута или состава multicast-группы без абсолютно надёжной транзакции удаления.

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

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

Четыре варианта распределяли домены отказа

RFC 2382 описал четыре семейства: сигнализация на VC данных; параллельный RSVP VC для каждой резервации; общий point-to-multipoint VC для сеансов с одинаковыми входом и множеством выходов; несколько point-to-point VC, совместно используемых сеансами.

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

Путь best effort отделял управление от нарушения на QoS VC, но не от перегрузки ATM. RFC 2382 требовал предпочтительного класса для управления. Приоритет в IP-планировщике до входа в ATM считался перспективным, но сложным и нуждавшимся в исследовании.

Выделенный сигнальный VC покупал изоляцию отдельным контрактом. Соответствующее требованиям управление не сбрасывалось из-за данных на другом канале. Цена: удвоенное минимальное число VC, дополнительная сигнализация ATM и задержка настройки.

Мультиплексирование требовало сохранять историю

Point-to-multipoint канал управления подходил нескольким сеансам, пока их вход и набор выходов совпадали. При изменении участников вход должен был найти другой VC, создать новый, изменить существующий или продолжить лишнюю передачу ушедшему получателю.

Экономия зависела от реальной топологии и рисунка трафика. Долгоживущие point-to-point VC в ядре могли распределить затраты настройки и использовать обратный канал, но их число всё равно определялось участвующими узлами. Повторное использование best-effort VC экономило соединение ценой большей вероятности потери.

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

Избыточный QoS мог помешать самому управлению

Большая QoS-квота для сигнализации не была бесплатным ответом. RSVP-сообщения редки, обычно приходят примерно раз в тридцать секунд, поэтому достаточно малого выделения. Завышенный запрос мог привести к отказу в сигнальном VC именно при дефиците ресурсов.

Fallback в best effort содержал тот же парадокс. Если QoS-вызов отвергнут из-за перегрузки ATM, управляющий пакет должен пройти ту же сеть с меньшей защитой. Наличие запасного пути не подтверждало его прохождение.

RFC 1755 уже стремился предотвращать connection thrashing правилами управления соединениями. RFC 2382 показал ещё один источник: потеря переноса управления, истечение состояния, разборка услуги и дополнительная работа по восстановлению.

Проверяемая цепочка включала генерацию сообщения, выбор VC и обработки, допуск, перенос через ATM, обновление до срока, сохранение VC данных и измерение услуги. Успех этапа не распространялся на следующий.

RFC 2382 не навязал единственную топологию. Он позволил сравнивать общие, отдельные и мультиплексированные пути, не смешивая их стоимость и доказательства. Минимум состоял в достаточной защите и наблюдаемости механизма, который делал soft state правдивым.