Кратко

  • RFC 2214 поместил backlog C, delay D, slack и RowStatus в строку SNMP для каждого интерфейса; все четыре объекта имели доступ read-create.
  • Эти значения описывали погрешность реализации и локальный выбор ресурсов. Они не подтверждали маршрут потока, сохранение резерва, составную границу RFC 2212 или измеренную задержку.

Четыре аккуратно подписанных поля легко принять за готовую гарантию. Backlog измеряется в байтах, Delay — в микросекундах, Slack показывает запас, Status сообщает состояние. Более того, RFC 2214 объявлял все четыре столбца read-create: система управления могла не только читать, но при поддержке реализации и создавать их.

Спецификация не превращала эту возможность в доказательство услуги. Fred Baker, John Krawczyk и Arun Sastry опубликовали RFC 2214 в сентябре 1997 года как расширение Integrated Services MIB для Guaranteed Service. Количественную модель гарантии определял RFC 2212. MIB показывала, как реальное устройство отклоняется от идеального fluid service и как оно может обменять временной запас на меньший локальный резерв.

C не измеряла текущую очередь

intSrvGuaranteedIfBacklog представлял C в байтах. RFC описывал его как backlog, вызванный особенностями реализации по сравнению со строгим побитовым обслуживанием. Для packetized weighted fair queueing в качестве примера предлагался максимальный размер пакета.

В RFC 2212 C был зависящим от скорости членом ошибки. При вычислении границы C делился на зарезервированную скорость R. Так можно было выразить эффект, продолжительность которого зависит от скорости передачи, например сериализацию датаграммы.

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

D не была временем конкретного пакета

intSrvGuaranteedIfDelay представлял D в микросекундах. D был независимой от скорости ошибкой элемента — наихудшим локальным изменением времени прохождения, которое не объяснялось C. RFC 2214 приводил путь от входного интерфейса через процессор к выходному и худший случай коллизий Ethernet.

Это значение могло определяться при загрузке или настройке. Оно не являлось наблюдаемой меткой времени пакета. Для сквозной границы локальные C и D требовалось сложить вдоль фактического пути в Ctot и Dtot. RFC 2212 оставлял сбор setup-протоколу, маршрутизации или иной функции управления.

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

Slack хранил принятое решение

Правило slack добавляло память. Если элемент использовал величину Si, чтобы уменьшить ресурсы для потока i, он должен был сохранить Si. При последующих reservation refresh того же потока следовало применять ту же величину без нового расчета. Это обеспечивало согласованность процесса резервирования.

В примере S = Dreq - (b/r + Ctot/r + Dtot). Промежуточный элемент мог использовать s <= S. RCSD scheduler увеличивал локальную границу задержки, а WFQ мог снизить зарезервированную скорость по правилам преобразования. Часть допустимого времени превращалась в экономию локального ресурса без увеличения ожидаемой сквозной границы.

Следовательно, slack не был свободной полосой или измеренной задержкой. Это был бюджет и запись о том, как он уже использован. Новый расчет при каждом refresh мог заставить одну и ту же заявку менять локальные обязательства. Сохранение Si предотвращало дрейф.

Однако строка RFC 2214 индексировалась по ifIndex. В ней не было полной идентичности потока, истории PATH/RESV и непрерывности refresh. Общая таблица потоков относилась к RFC 2213, а receiver-oriented soft state RSVP — к RFC 2205. Для проверки согласованности эти свидетельства нужно было связать.

Возможность записи показывала власть, не эффект

Security Considerations указывали важное различие: SNMP SET мог создать RSVP- или Integrated Services-резервирование по правилам, отличным от RSVP negotiation.

Успешный SET поэтому не означал согласие получателя. Он не доказывал продолжение soft state, решение admission control для нужного субъекта, реальную классификацию пакетов или работу scheduler.

RowStatus также не завершал цепочку. RFC 2214 применял статус к интерфейсам, настроенным для Guaranteed Service. В общей конвенции active означает, что conceptual row доступна managed device. Это локальное состояние строки, а не вывод о пути.

Историческое значение RFC 2214 — в видимости ограниченных утверждений. C описывала зависящее от скорости отклонение, D — независимое от скорости время, slack — выбор между временным запасом и ресурсами, который должен пережить refresh. Таблица была полезным реестром именно пока ее запись не выдавали за итог услуги.

Источники