Кратко

  • RFC 1272 утверждала, что по конечным IP-адресам провайдер не мог определить, какой соседний административный домен перенёс трафик через границу сети.
  • Пограничные измерители могли помочь сверять отчёты, но полезная детализация зависела от топологии, гранулярности, хранения, стоимости сбора и безопасности.
  • Меморандум отделял отчёты об использовании от оплаты и исполнения политики и оставлял открытым вопрос, считать ли пакеты на входе в маршрутизатор или на выходе.

Не хватало имени соседа

У IP-пакета есть адрес источника и адрес назначения. Это позволяет считать трафик между конечными узлами, но само по себе не показывает, какая соседняя сеть ввела пакет в административный домен провайдера. Если трафик одного конечного узла может приходить через разные соседние домены, даже полная запись конечных адресов не отвечает на более узкий вопрос провайдера: через какую сеть этот трафик пересёк мою границу?

RFC 1272 не предлагала каждой сети учитывать использование Интернета каждым пользователем. Модель сосредоточивалась на домене одной администрации и непосредственно подключённых к нему соседних доменах. Провайдер мог измерить трафик через границу с соседом и обменяться с ним отчётом. Если сосед хотел распределить собственные затраты дальше по цепочке, это становилось его ответственностью. Учёт был рекурсивным: каждая администрация отвечала за отношения, которые могла наблюдать, не притворяясь, что видит конечного пользователя по всему миру.

Это меняет смысл места измерения. Хост наблюдает трафик на конечном узле. Маршрутизатор на административной границе видит трафик, входящий в локальный домен или выходящий из него, и может дать сведения о соседнем соединении. Меморандум отмечал: IP-заголовки сами по себе не содержат идентификатор промежуточной системы; могут понадобиться данные нижних уровней или конфигурация пограничного оборудования. Конечные адреса и граница учёта отвечают на разные вопросы.

Измерение тоже чего-то стоит

Место установки было лишь одним решением. RFC 1272 описывала отдельные сетевые мониторы, линейные измерители, программные измерители в маршрутизаторах и координируемые наборы «router spiders». Оптимальное место зависело от топологии и услуги. Измерение на границе могло помочь провайдеру и потребителю сверить данные, но это не означало, что нужно оснащать каждый маршрутизатор.

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

Это разные стандарты доказательности.

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

Отчёт — не счёт и не правило

RFC 1272 прямо ограничивала свою задачу: дать справочную основу для архитектуры отчётов об использовании, а не установить интернет-стандарт. Такие отчёты могли помочь абоненту понять своё поведение, провайдеру — оценить соблюдение политики, или сторонам — распределить затраты. Но одни отчёты не обеспечивают исполнение политики, и документ не рекомендовал методы оплаты. Он также не решал, кто должен платить за повторно отправленные пакеты.

Один вопрос авторы намеренно оставили открытым: считать пакет при получении маршрутизатором или только после пересылки? Во время перегрузки маршрутизатор может отбросить пакеты. Подсчёт на входе отражает ресурсы, потраченные на предложенный трафик; подсчёт на выходе не позволяет выставлять счёт за непереданный трафик. RFC 1272 требовала поддерживать оба варианта, поскольку выбор зависел от контекста и политики, а не от универсального технического правила.

Позже RFC 2722 определила архитектуру измерения потоков трафика. Эта работа продолжила историю измерений, но не доказывает, что конкретная модель оплаты или всё видение учёта 1991 года стали практикой. Устойчивый вопрос RFC 1272 уже: что администрация действительно может узнать на своей границе и сколько измерений стоит оплачивать? Нужно сохранять цепочку от наблюдаемого потока к определённому соседу, отчёту и последующему решению о цене или контроле. Из конечных IP-адресов ничего этого автоматически не следует.

Источники: RFC 1272; RFC 2722; RFC 2990.