Кратко
- RFC 3483 разделила мониторинг, накопление, передачу и очистку данных: PDP мог приостановить отчёты, пока PEP продолжал считать использование политики.
- Значение числа зависело от расписания, истории очистки и идентичности реального назначения, а деактивация контекста и удаление состояния требовали заключительных отчётов.
Пустое место на графике часто принимают за ноль. В модели RFC 3483 оно сначала означало лишь отсутствие нового сообщения. Точка применения политики, PEP, могла по-прежнему наблюдать использование и хранить накопленное значение, тогда как точка принятия решений, PDP, временно запретила незапрошенные отчёты. Молчал канал, но не обязательно измеряемая система.
Такое различие вытекало из трёх частей схемы. Критерии выбора определяли объекты наблюдения. Класс обратной связи задавал измеряемые показатели. Политика связи соединяла объект с показателем и устанавливала условия отправки. Полученное число было результатом именно этой комбинации, а не самодостаточным итогом.
Accounting Timer ограничивал частоту незапрошенных сообщений учётного типа. Он предназначался для регулирования потока, а не для точной синхронизации. Конкретная политика могла ждать несколько базовых интервалов, срабатывать по порогу, сообщать только при изменении или отправлять данные периодически даже без изменений. Поэтому отсутствие пакета в ожидаемую оператором секунду не доказывало отсутствие измерения.
Нулевое значение таймера особенно хорошо показывало границу. PEP не посылал незапрошенную обратную связь, но продолжал отслеживать использование согласно политике PDP. Результат хранился до прямого запроса. Ноль описывал частоту самостоятельной отправки, а не содержимое счётчика.
Приостановка тоже имела два смысла. PDP мог остановить только отчётность, сохранив мониторинг и накопление. Он мог остановить сам мониторинг, и тогда новые данные не появлялись. В обоих случаях команда указывала, нужно ли перед переходом отправить текущий результат, и могла относиться к одной политике или ко всем. Запись «приостановлено» без этих деталей теряла главное различие.
Запрошенный отчёт мог появиться в середине периода. PDP требовал немедленную обратную связь, PEP отвечал и при необходимости очищал переданные атрибуты. Но исходное периодическое расписание сохранялось: запрос не переносил следующую границу. Два близких отчёта могли быть правильными — один отвечал на запрос, второй приходил по ранее заданному графику.
Складывать их можно было только после проверки очистки. Если первый отчёт обнулил показатель, второй отражал короткий остаток периода. Если очистки не было, значения могли перекрываться. Время передачи нельзя подменять интервалом измерения, а один отчёт — всей историей счётчика.
RFC 3483 отдельно разобрала принадлежность числа. Некоторые объекты COPS прямо соответствовали уникальной конфигурации PEP. Другие были общими и порождали несколько реальных назначений, способных вести независимую статистику без отдельных объектов COPS. Критерии выбора и запись обратной связи вместе должны были идентифицировать самую мелкую поддерживаемую гранулярность.
Например, к IP-адресу можно было добавить порт и отличить фактическое назначение. Предпочтительным считался полный уникальный ключ уже в критериях выбора. Допускался и необязательный вариант: широкие критерии выбирают несколько назначений, а отчёт содержит недостающий признак. Тогда соединение обеих записей становится необходимой частью доказательства.
Контексты задавали временную границу. COPS-PR позволял хранить несколько независимых наборов политик, но активным был только один. Использование отслеживалось, записывалось и передавалось, пока соответствующий контекст был активен. При деактивации PEP отправлял заключительный отчёт, после чего не собирал по этому контексту новые данные.
Delete Request State создавал ещё одну обязательную развязку. Непосредственно перед удалением PEP должен был отправить всё оставшееся использование, даже если удаление начал PDP. Сначала сохранялся последний фрагмент свидетельства, затем исчезало состояние, придававшее ему смысл.
Разрыв соединения не давал локальному счётчику бессрочного права продолжать работу. PEP отслеживал использование только пока применял кэшированную политику. Когда политика истекала, истекали и данные обратной связи, а мониторинг прекращался. После восстановления связи PDP явно разрешал возобновить отчётность; PEP передавал сохранённое использование и принимал новый Accounting Timer.
Жизнь доказательства следовала жизни реально исполняемого решения, а не жизни процесса или строки базы данных. Отключение не стирало измерения, сделанные под действующей политикой. Но новое соединение не создавало непрерывность после её истечения.
Документ не обещал большего. Он имел статус Informational и описывал рамочную схему, а не систему расчётов. Тарификация, выставление счетов и внешние учётные события были вне области. Точное содержание запрашивающего Decision оставалось будущим спецификациям. Источники не подтверждают конкретное внедрение, точность счётчиков, совместимость поставщиков, правильность начислений или качество услуги.
В этом её отличие от соседних работ. RFC 3060 занималась данными политики и локальной оценкой. RFC 3084 — транзакциями предоставления, кэшем и восстановлением связи. RFC 3159 — идентичностью строк PRID. RFC 3483 начинала после установки правила и спрашивала, какое свидетельство использования возникло, когда оно было передано и какому назначению принадлежало.
В логике слоёв реальности Heng Lu проверка начинается с активного контекста и фактического назначения. Затем соединяются выбор, показатель и условия передачи. Таймер, порог, условие изменения и очистка помещаются на одну временную шкалу с запросами, паузами, возобновлениями и финальными отчётами. При сбое доказательство обрывается там, где закончилась кэшированная политика.
Лишь после этого тишина получает смысл. Возможно, использования не было. Возможно, незапрошенные отчёты были отключены, передача приостановлена, период ещё не завершился или значение ждало запроса. Исторический урок RFC 3483 состоит в том, что отсутствие услышанного нельзя выдавать за отсутствие произошедшего.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
