Кратко

  • RFC 2379 рекомендовал передавать управляющие сообщения RSVP по уже существующему пути best effort, даже если эти сообщения должны были привести к созданию отдельных виртуальных каналов ATM с заданными параметрами качества обслуживания.
  • PATH или RESV, состояние RSVP, решение о допуске, настроенный VC и наблюдаемая работа приложения — последовательные свидетельства; ни одно из них не доказывает всю цепочку.

Просить гарантию по пути без гарантий

RSVP предназначался для запроса резервирования ресурсов, а ATM умел создавать виртуальные каналы с определёнными характеристиками обслуживания. Тем не менее RFC 2379 не требовал сначала строить защищённый канал для самой сигнализации. При unicast сообщения шли по VC, уже ведущему к получателю, а при multicast — по обычному пути best effort к группе.

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

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

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

Одно резервирование — один VC

ATM подталкивал к агрегации. Несколько сеансов RSVP теоретически могли делить канал и экономить ресурсы. Однако в 1998 году агрегация ещё оставалась исследовательской темой. Поэтому RFC 2379 советовал отдельный VC для каждого резервирования RSVP.

Такая осторожность делала преобразование наблюдаемым. Сеанс RSVP не являлся ATM-каналом. Требовалось отобразить запрос в параметры ATM, принять решение о допуске, создать или выбрать VC и классифицировать трафик. Наличие VC, в свою очередь, не доказывало, что пакеты получили запрошенное обслуживание.

Сопутствующие документы намеренно делили работу. RFC 2380 задавал требования к реализации; RFC 2381 сопоставлял controlled-load и guaranteed service из Integrated Services с ATM; RFC 2382 описывал общий каркас. Такое разделение не позволяло одному успешному сигналу заменить успех всех этапов.

Shortcut наследовал конечную точку

ATM shortcut мог пересекать границы логических IP-подсетей, из-за чего PATH и RESV шли асимметричными маршрутами. RFC 2379 опирался на уже определённое поведение RSVP — объект NHOP и пересылку сообщения, пришедшего не на тот интерфейс, — чтобы справляться с асимметрией.

Главное правило касалось права выбирать конечную точку. QoS shortcut не должен был самостоятельно изобретать место завершения. Если best-effort трафик уже выбрал конечную точку shortcut, запущенный RSVP QoS VC использовал ту же точку. В рекомендованной модели отсутствие best-effort shortcut означало и отсутствие QoS shortcut через границы подсетей.

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

Multicast не сводился к одной модели

Получатели одного multicast-сеанса могли просить разные уровни QoS или не просить их вовсе. Сопутствующий каркас различал полную неоднородность, ограниченную неоднородность, однородность и модифицированную однородность. RFC 2379 не объявлял единственного правильного варианта. Следовало поддерживать как минимум ограниченную неоднородность или модифицированную однородность, а лучше обе с механизмом выбора.

Эта сдержанность тоже важна для истории Интернета. Документ не стирал операционные различия ради аккуратной схемы. Он устанавливал выполнимый минимум и оставлял различия между получателями наблюдаемыми.

Четыре разные квитанции

Строгое прочтение разделяет путь best effort, перенёсший управление; состояние RSVP и его обновления; результат допуска и настроенный ATM VC; а также счётчики и наблюдения приложения, показывающие полученную услугу.

Отправка PATH не доказывает возврат RESV. RESV не доказывает допуск. Живой VC не доказывает правильную классификацию. Метка QoS не измеряет задержку, потери или доставку. Архитектура связывала эти уровни, не объявляя их одним целым.