Кратко

  • SENDER_TSPEC, ADSPEC и FLOWSPEC имели разных авторов и разные направления: декларация источника шла вниз, сводка пути составлялась по дороге вниз, запрос получателя шёл вверх.
  • Общий break bit означал, что хотя бы один элемент не поддерживает RSVP/Integrated Services; после этого остальные параметры ADSPEC нельзя было считать надёжной характеристикой пути от конца до конца.
  • Сервисный break bit обозначал более узкий разрыв: RSVP-осведомлённый элемент не предоставлял конкретную услугу.
  • PATH_MTU уменьшалась по пути и при слиянии резервирований, тогда как исходный максимум пакета в TSpec отправителя оставался неизменным; более крупные пакеты могли получать только best effort.
  • Чистая реклама, принятый запрос, объединённый FLOWSPEC или вычисленная граница задержки не доказывали неизменность маршрута, соблюдение профиля, фактическое обслуживание и успех приложения.

Сводка была компактной именно потому, что не была журналом

ADSPEC строилась по модели One Pass With Advertising.

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

Такой формат экономил сигнальное пространство и одновременно скрывал подробности.

Полоса представляла результат композиции, а не последовательность всех локальных значений. PATH_MTU хранила минимум, не обязательно указывая место ограничения. Параметры Guaranteed service объединялись по математическим правилам, а не сохраняли каждое промежуточное действие.

Из-за этой потери деталей требовался отдельный сигнал о целостности самого процесса.

Когда элемент не мог участвовать в RSVP/Integrated Services, общий break bit фиксировал разрыв. RFC 2210 требовала считать прочие параметры ненадёжными. Это не утверждение, что каждое число ложно. Это запрет использовать частичные вычисления как доказательство непрерывного пути.

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

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

Их локальная компетентность не делала предыдущий участок участником композиции задним числом.

Поэтому break bit был памятью о происхождении сводки. Он отвечал не только на вопрос «что умеет текущий узел», но и на вопрос «сохранилась ли предпосылка на всём пройденном пути».

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

Отправитель объявлял, но не измерял

SENDER_TSPEC создавался источником и передавался downstream.

Он описывал возможный трафик с помощью token bucket и максимального размера пакета M. Промежуточные элементы пересылали исходную декларацию без переписывания под собственные ограничения.

Это сохраняло авторство факта.

TSpec не означал, что реальный поток обязательно будет соответствовать профилю. Он не измерял доступную полосу и не фиксировал решение admission control. Он давал входные данные для дальнейших проверок.

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

Путь рекламировал, но ещё не резервировал

ADSPEC также шёл downstream, однако формировался сетью.

Общий блок мог содержать число Integrated Services hops, полосу пути, минимальную задержку и составной MTU. Блок Guaranteed service добавлял члены для расчёта задержки.

Получатель использовал эту информацию при выборе запроса. Сама реклама не была положительным решением о ресурсах.

Даже при нулевом break bit маршрут мог измениться после прохождения PATH. Политика и доступность ресурсов могли быть другими при получении RESV. Неподнятый признак означал лишь отсутствие зарегистрированного разрыва данного типа в данной рекламе.

Это ограниченное, но полезное доказательство. Ошибка начинается тогда, когда его превращают в обещание будущего.

Получатель формировал намерение

FLOWSPEC создавался получателем и шёл upstream в RESV.

Получатель сопоставлял требования приложения, TSpec отправителя, ADSPEC и локальную политику. Для Guaranteed service составные параметры помогали выбрать резервирование, соответствующее желаемой границе задержки. Для Controlled-Load применялась собственная семантика услуги.

FLOWSPEC выражал запрос.

Каждый RSVP-узел передавал TSpec и FLOWSPEC соответствующему traffic-control service. Локальная политика и admission control ещё могли отказать. Несколько запросов могли сливаться, поэтому объект, продолжавший движение к отправителю, не обязательно совпадал с исходным запросом одного получателя.

Слияние показывало состояние управления в данной точке. Оно не было квитанцией о фактической обработке пакетов.

Общий разрыв и разрыв конкретной услуги

Общий bit относился к способности пути участвовать в RSVP и Integrated Services. Его установка подрывала основание общей сводки.

Сервисные bits отвечали на более точный вопрос.

Элемент мог понимать RSVP и обрабатывать общий формат, но не реализовывать Guaranteed service. Тогда общая сигнальная архитектура сохранялась, а отсутствие конкретной услуги отмечалось отдельно.

Это различие не позволяло приписывать RSVP-узлу поддержку всех услуг. Одновременно отсутствие одной услуги не выдавалось за полное отсутствие RSVP.

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

Три значения размера пакета описывали три реальности

M в Sender TSpec показывал максимальный пакет, который источник мог создать.

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

Исходный TSpec не изменялся.

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

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

Controlled-Load не обещал конкретную цифру

RFC 2211 описывала Controlled-Load как обслуживание, приближающее для соответствующего потока условия ненагруженной best-effort сети. Оно использовало admission control, но не задавало фиксированной численной гарантии задержки или потерь.

Поэтому его блок ADSPEC не содержал набора составных членов Guaranteed service. Сервисный break bit всё равно был нужен, чтобы показать отсутствие самой услуги.

Операционная система не должна выводить точную SLO только из названия Controlled-Load. Такой вывод добавил бы обещание, которого нет в спецификации.

Guaranteed давал строгий, но условный расчёт

Для Guaranteed service значения Ctot, Dtot, Csum и Dsum объединялись по RFC 2212. Вместе с профилем трафика они позволяли вычислить границу задержки в очереди.

Сила этой границы зависела от сохранения условий.

Поток должен был соответствовать TSpec. Элементы должны были предоставлять услугу. Запрос должен был пройти admission. Параметры должны были оставаться применимыми к маршруту. И даже тогда вычисление ничего не говорило о том, завершило ли удалённое приложение свою работу.

Точная формула не превращает свои предпосылки в необязательные примечания.

Протокол настройки не владел всей семантикой

RSVP мог переносить объекты QoS как непрозрачные данные, тогда как сервисные модули интерпретировали их поля.

RFC 2205 определяла PATH, RESV и soft state. RFC 2211 и RFC 2212 определяли услуги. RFC 2215 различала локальные и составные параметры. RFC 2216 описывала услугу отдельного сетевого элемента. RFC 2210 связывала эти уровни.

Благодаря разделению успех сигнализации не становился автоматически доказательством услуги. Локальная поддержка не становилась поддержкой всего пути. Корректный FLOWSPEC не заменял политику и аутентификацию доступа к QoS.

Семантика стандарта, а не история внедрения

RFC 2210 опубликована в сентябре 1997 года как Proposed Standard. Источники позволяют уверенно описывать форматы, направления и правила композиции.

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