Кратко

  • В области агрегации внутренние маршрутизаторы не обрабатывали сквозные RSVP-сообщения, а множество потоков ехало внутри агрегатной резервации, связанной с DSCP. Исчезало состояние в ядре, но не обязанность доказать допуск каждого потока.
  • Деагрегатор выбирал отображение, возвращал DSCP в DCLASS и прибавлял token bucket к учёту использования. Агрегатор классифицировал и маркировал пакеты. Эти действия нельзя свести к одной отметке «готово».
  • Размер блока мог определяться прогнозом и намеренно не совпадал с точной суммой. Ошибочно направленный RSVP-E2E-IGNORE мог потеряться без явного сигнала. Поэтому требовалась связанная цепочка квитанций от обеих границ до наблюдаемого трафика.

Точность умножалась на число маршрутизаторов

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

RFC 3175 переместила границу знания. Резервации с общими входом и выходом могли проходить через область в одном крупном резерве. Первый пограничный маршрутизатор становился агрегатором, последний — деагрегатором; внутренние узлы обслуживали класс, не ведя карточку каждого участника.

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

Номер 134 задавал область незнания

На входе агрегатор менял IP protocol number RSVP на RSVP-E2E-IGNORE, которому IANA присвоила 134. Внутренние узлы пересылали Path, не создавая per-flow state. На правильном выходе деагрегатор восстанавливал RSVP.

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

Поэтому запись о входе должна соединяться с квитанцией выхода. Молчание ядра означало масштабируемость; молчание деагрегатора — разрыв управления.

DSCP называл класс, но не владельца обещания

DSCP обозначали трафик агрегатов, а PHB — обработку на каждом переходе. Локальная политика могла разнести Guaranteed Service и Controlled Load по разным классам.

Решение принимал деагрегатор: он первым получал Resv от получателя и сведения о требуемом сервисе. Выбранный DSCP возвращался в DCLASS. Агрегатор сохранял соответствие, удалял DCLASS перед отправкой Resv к источнику и маркировал подходящие пакеты.

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

Индивидуальный допуск остался на выходе

При достаточной полосе деагрегатор прибавлял token bucket из E2E Resv к внутреннему учёту агрегата и отправлял сигнал обратно. Именно этот счёт скрывается за внешней простотой общего блока.

Существующий резерв не принимал следующую заявку автоматически. Нужно было выбрать сессию, увидеть уже выданные обязательства, применить политику и проверить остаток. Если был только aggregate Path, создавался Resv; при нехватке блок увеличивался, либо заявка ждала или отклонялась.

Число внутренних состояний могло не зависеть от числа участников. Пограничный журнал такой свободы не имел. В этом и состояла экономия.

Точная сумма вернула бы сигнализацию

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

Частые корректировки экономили резерв, но увеличивали сообщения. Редкие сокращали изменения, но повышали ошибку, запас и цену восстановления. Документ не объявлял один алгоритм обязательным для всех.

Прогноз, настроенный объём, занятый объём, решение о допуске, состояние scheduler и доставка — разные величины. Общий зелёный индикатор стирает неопределённость, а не устраняет её.

Радиус отказа стал общим

В агрегате ослабевала изоляция: всплеск одного потока мог задержать другой. Упомянутые в RFC результаты измерений относились к изученным условиям и не описывают неизвестную современную сеть.

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

Криптографическая целостность тоже не объединяла факты. Для скрытых сообщений края были логическими RSVP-соседями, а агрегатные сообщения внутри защищались hop-by-hop. Валидный digest подтверждал сообщение и владение настроенным ключом в своём контексте, но не ёмкость, отображение, маркировку или доставку.

Последующие RFC показали предел первой модели

RFC 4804 перенесла агрегацию на MPLS TE/DS-TE tunnels. RFC 4860 ввела generic aggregate, поскольку RFC 3175 не позволяла несколько агрегатов с одинаковыми source, destination и PHB. RFC 5350 обновила правила Router Alert. В реестрах IANA сохранились 134 и aggregate C-Types.

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

Поздние идеи Lu Heng о running code, минимальной общей спецификации и слоях реальности используются здесь как явно раскрытая аналитическая рамка, а не слова авторов RFC. Реестр, политика, конфигурация, действие и результат не должны заимствовать доказательность друг у друга.

Источники и ограничения

Доказательства зафиксированы 2 октября 2026 года в часовом поясе Asia/Shanghai. Они подтверждают механизм, назначения IANA и развитие спецификаций, но не реализацию, распространённость, измеренную экономию, трафик, производительность, инцидент, действия оператора или доставленное качество.