Кратко
- В RFC 3423 транспортное подтверждение выявляло потерю пакета или молчащий сервер, а DATA ACK протокола CRANE продвигался лишь после правильной обработки непрерывной последовательности и помещения учётных данных в постоянное хранилище.
- Даже такой ACK не доказывал итоговый расчёт: полнота DSN, переключение серверов, устранение дублей, версия шаблона, защита канала и финансовый результат оставались разными свидетельствами.
Сбой после успешной передачи
Сетевой элемент отправляет запись об использовании. Надёжный транспорт доставляет байты и получает ACK. Затем удалённый процесс падает между разбором и фиксацией. Сеть вправе считать свою операцию успешной, но учётная система ещё не вправе считать запись сохранённой.
Этот промежуток стал основой RFC 3423, опубликованного в ноябре 2002 года. Документ описывал Common Reliable Accounting for Network Element компании XACCT Technologies. Текст RFC, информационная страница, карточка IETF, история, ссылки и поиск исправлений фиксируют его статус: Informational, не стандарт Интернета и не измерение современного распространения.
CRANE предназначался для большого потока учётных данных от сетевых элементов к посредническим системам, BSS и OSS. Важнее конкретного продукта оказалось правило: надёжность транспортировки и надёжность записи принадлежат разным слоям.
Транспорт не вёл бухгалтерскую книгу
Под CRANE требовался надёжный, соединительный и упорядоченный транспорт. Можно было использовать TCP или исторический SCTP из RFC 2960; документ предпочитал SCTP за границы сообщений и быстрое обнаружение отказа. Это проектное предпочтение, а не факт внедрения.
Транспортные ACK помогали замечать потерянные пакеты и неотвечающие серверы. CRANE подтверждал сообщение после обработки и помещения учётной информации в постоянное хранилище. Первый сигнал относился к каналу, второй — к состоянию принимающего приложения.
RFC 2975 уже включал энергонезависимое хранение и устранение дублей в общую модель управления учётом. RFC 3423 сделал часть этой границы наблюдаемой. Живое соединение переставало быть заменой сохранённой записи.
DSN обозначал непрерывный рубеж
Каждое DATA-сообщение несло Data Sequence Number. После запуска или перехода на новый сервер клиент отмечал первую запись битом S для синхронизации. Каждый новый DATA увеличивал DSN на единицу. Сервер принимал последовательные записи и отбрасывал опередившие очередь.
DATA ACK содержал DSN последнего правильно обработанного сообщения в непрерывном отрезке. Увидеть 3123 без 3122 недостаточно, чтобы подтвердить 3123. Сервер повторял текущий рубеж и тем самым требовал немедленной передачи пропуска.
Рубеж не означал правильную тарификацию, верного абонента, выставленный счёт или расчёт. Он не обещал вечную сохранность носителя. Это было ограниченное утверждение конкретного получателя в конкретной сессии и конфигурации.
Одна последовательность жила на нескольких серверах
Сессия могла включать резервные серверы с приоритетами. Клиент выбирал самый приоритетный из тех, что считал работающими. Если не было ни одного, записи ждали в локальной очереди до восстановления или исчерпания места; переполнение требовало сигнала тревоги.
Переход мог последовать после сообщения транспорта о молчащем порте, превышения объёма неподтверждённых данных на заданное время, STOP от активного сервера или возврата более приоритетного. Точный алгоритм оставался реализацией.
Числовой пример особенно нагляден: сервер 1 получает 3042–3095, сервер 2 — 3096–3122, сервер 1 снова принимает с 3123. Ни один сервер не содержит всю историю. Полноту обязан обеспечить отправитель для посреднической или биллинговой системы.
Повторная отправка другому серверу выставляла бит Duplicate. Нижестоящая система использовала DSN для устранения копий. Бит сообщал о вероятности дубля, а не доказывал его наличие или успешное удаление.
Неверно понятые байты можно сохранить идеально
CRANE экономил полосу благодаря заранее согласованным шаблонам. Шаблон задавал порядок, тип и смысл ключей; ключи можно было включать и отключать. Все серверы одной сессии должны были разделять набор и состояние.
Запись несла Template ID и Configuration ID. Короткая история позволяла читать старые конфигурации. Порядок транспорта должен был не допустить преждевременную будущую версию; смена шаблона ожидала ACK данных старой версии.
Каждый сервер получал одну возможность предложить изменение. Клиент выбирал окончательный набор и рассылал FINAL TMPL DATA; после этого получатели обязаны были принять его без новой правки. Правило останавливало цикл и показывало центр решения.
Постоянное хранение без контекста конфигурации может надёжно сохранить неправильное толкование. Целостность байтов и целостность смысла различны.
Соседние протоколы не давали одинаковых гарантий
Во введении сравнивались RADIUS и Diameter. RFC 2865 описывает доступ RADIUS, RFC 2866 — RADIUS Accounting. Diameter был опубликован в RFC 3588, затем заменён RFC 6733. RFC 3334 формулирует требования policy-based accounting.
Более поздний IPFIX даёт другой контекст: протокол, информационная модель, рекомендации реализации. Они показывают повторяющиеся задачи экспорта и шаблонов, но не доказывают внедрение CRANE, прямую преемственность или совместимость.
Нормативные слова следуют RFC 2119. MUST подтверждает требование текста, но не поведение работающего кода.
Безопасность не входила в DATA ACK
RFC 3423 признавал, что CRANE сам не обеспечивал сильную конфиденциальность и целостность. Статически настроенные адреса упорядочивали доверие, но без дополнительной защиты оставались уязвимыми для подмены. В зависимости от среды рекомендовались IPsec или TLS.
Следовательно, DATA ACK сам по себе не аутентифицировал партнёра и не доказывал неизменность сообщения. Канал, личность, полномочие, шаблон, хранение и деловой результат требовали отдельных проверок.
Источники и пределы
Метод также опирается на тексты Heng Lu об уровнях реальности и работающем коде как первичном источнике. Спецификация, бинарный файл, настройка, наблюдение, хранилище и счёт связаны, но не заменяют друг друга.
Источники подтверждают механизм и исторический контекст. Они не подтверждают современное применение, измеренную производительность, названный инцидент, действующий продукт или соответствие конкретной установки.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
