Кратко

  • RFC 3387 показал недостающий слой над механизмами QoS: классификация и приоритет могли работать раньше, чем появлялась определённая, разрешённая, проверяемая и оплачиваемая услуга.
  • Документ распределил функции между доступом, ядром и границами доменов и предупредил, что премиальные резервы и централизация способны ослабить обычный best effort.

На спор о качестве каждая сторона приносит свой документ. Маршрутизатор предъявляет счётчик приоритетного класса. Биллинговая система предъявляет запись использования. Клиент предъявляет сорванную операцию. Эти свидетельства не обязательно противоречат друг другу: они относятся к разным ступеням.

RFC 3387 был опубликован в сентябре 2002 года со статусом Informational авторами из IRTF Service Management Research Group. Он не создавал новый протокол и не описывал готовое коммерческое внедрение. Его вопрос состоял в том, какие функции отсутствовали вокруг IntServ, DiffServ, policy и traffic engineering, чтобы техническое различение стало управляемой услугой.

Best effort соответствовал раннему принципу простоты и отсутствия централизованного контроля. QoS добавлял решение о дефиците. Если один поток получает больше, оператор должен определить обещание, проверить полномочия заявителя, выделить ресурсы и сохранить доказательства для пути через независимые сети.

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

На краю доступа различались аутентификация, авторизация и admission control. Первая устанавливает личность, вторая разрешает действие, третья проверяет наличие ресурсов. Там же нужны контроль параметров трафика, интерфейсы учёта, проверка услуги, уведомление об отказе, повторное создание и прекращение. Разрешённый запрос может остаться недопущенным, и этот статус нельзя скрывать.

Ядро отвечало за traffic engineering, настройку устройств, публикацию ресурсов, обнаружение отказов и восстановление. RFC 3387 рассматривал более централизованный расчёт, потому что отдельный маршрутизатор не видел всей нужной информации. Но глобальный обзор не означал автоматического права управлять всеми доменами: документ одновременно спрашивал о сложности и риске дестабилизации.

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

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

Биллинг и безопасность требовалось проектировать при создании услуги. RFC 2975 отделяет accounting, который собирает данные об использовании, от charging, применяющего цену, и billing, выставляющего требование. Расчёт по требованию — ещё одно событие. Точный счётчик может сочетаться с неверным тарифом; верный счёт может быть не оплачен; оплата не доказывает техническое исполнение.

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

Риск затрагивал и тех, кто не покупал премиальный класс. Зарезервированная ёмкость могла простаивать, оставаясь недоступной best effort. Доход создавал стимул отдавать больше платному трафику. Документ не сообщал об измеренном ущербе, но выявлял конфликт, который архитектура и мониторинг не должны скрывать.

Принцип Running-Code Primacy Лу Хэна задаёт границу общей части. Совместными должны быть минимальные детерминированные правила идентичности, полномочий, параметров, измерения, безопасности и взаимодействия. Внутреннее распределение ресурсов и цены остаются локальными. Реестр, проверяющий или брокер может переносить свидетельства, не становясь властителем их истинности.

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

Источники