Кратко

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

Одна политика означала несколько действий

RFC 1104 написал H-W. Braun из Merit/NSFNET; документ датирован июнем 1989 года. Он не провозглашал готовую универсальную архитектуру, а перечислял модели ради обсуждения масштабируемой маршрутизации по правилам. Нынешняя карточка RFC Editor указывает статус Unknown, а IETF Datatracker относит публикацию к Legacy и не даёт ей формального положения в процессе стандартов IETF.

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

Все четыре системы могли отчитаться об исполнении политики. Но без названия объекта и контроллера невозможно понять, изменилась ли карта, сработал ли локальный фильтр, была ли выдана ёмкость или только появился показатель.

Распространение маршрутов меняло пространство выбора

Первая модель действовала в масштабе сетей и Administrative Domains. Политика определяла, какие сведения принимать, использовать и передавать. В результате сеть появлялась или исчезала из конкретного представления о маршрутах.

Историческим примером служил интерфейс NSFNET: проверка исходного адреса соседа, домена или AS, объявленных сетевых номеров и метрик через базу политик. Эти четыре проверки уже использованы как вспомогательный материал в опубликованной статье Sofia Ren о RFC 1074. Они не являются открытием или тезисом новой статьи.

Граница, которую провёл RFC 1104, важнее примера. Распространение маршрутов не выполняло пакетную фильтрацию и само по себе не предотвращало вредоносный трафик, введённый через source routing. Отсутствующий маршрут исключал возможность в одной картине, но не объяснял автоматически каждый потерянный пакет. Существующий маршрут предлагал выбор, но не подтверждал его использование или доставку.

Маршрутное свидетельство должно называть объект, соседа, область, версию политики и получившееся состояние. Таблица не может свидетельствовать о пакете, которого не наблюдала.

Фильтр отвечал только за свою точку

Вторая модель рассматривала отдельный пакет. Устройство сопоставляло доступные поля с правилом и локально пересылало или отбрасывало. Такая детализация могла дойти до хоста или пользовательской метки, в отличие от сетевого масштаба первой модели.

Точность требовала ресурсов. RFC 1104 предупреждал о нагрузке на маршрутизатор и о больших базах политик, которые должны оставаться согласованными. Для исторического объяснения важна не только формулировка правила, но и версия, реально загруженная во время решения.

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

Допустимое утверждение узко: этот наблюдаемый пакет в этой точке при этой версии правила получил такое локальное действие. Расширение требует другого источника.

Выданный ресурс уменьшал чужую возможность

Третья модель охватывала полосу, буферы, каналы и приоритет очередей. RFC 1104 называл её в основном ортогональной распространению маршрутов, признавая взаимодействие.

Маршрут мог существовать без резервирования. Принятый пакет мог ждать без ожидаемой ёмкости. Ресурс мог быть выделен заранее, а достижимость исчезнуть дальше. Разрешение двигаться и предоставление средств для движения были разными состояниями.

Ресурс был конкурентным. Предпочтение одному потоку могло уменьшить долю другого. Междоменное выделение становилось вопросом полномочий: кто вправе занять ресурс, которым управляет другая сторона? Документ ставил вопрос, а не сообщал о состоявшемся резервировании.

Существовал и выбор затрат. Можно расходовать вычисления, память и управление на принуждение к правилам дефицита, а можно снижать сам дефицит. Возможность записать правило не доказывала экономическую разумность его исполнения.

Учёт описывал прошлое, но не разрешал его

RFC 1104 отделял accounting от policy routing, хотя связывал их. Маршрут, объём и другое использование можно было измерять на уровне домена, сети, хоста или пользователя, а затем учитывать в новых решениях.

Счётчик не объявлял маршрут, не открывал фильтр и не резервировал буфер. Его число зависело от единицы, точки, времени и правила присвоения. Внутреннее измерение одного домена также не обязательно описывало сквозную услугу нескольких доменов.

RFC 1125 позднее разделил charging policy на единицу, основу измерения, сумму, плательщика, принимаемый счётчик и пределы. Примеры не были официальными политиками. Однако структура показывала: верному числу всё ещё нужны правило отнесения и полномочный субъект, прежде чем оно станет требованием.

Несовпадение четырёх следов было результатом

Маршрут мог присутствовать, а фильтр — отказать. Фильтр мог разрешить, а очередь — не дать ёмкости. Ёмкость могла быть зарезервирована без использования. Измерение могло существовать без определённого ответственного. Это не шум, а границы знания разных систем.

Единое поле «выполнено» стирало причину: отсутствие пути выглядело как блокировка, разрешение — как предоставленная услуга, резерв — как потребление, потребление — как долг. Архив должен сохранять контроллера, версию, время, область, маршрутное состояние, локальное действие, ресурс, единицу и последующее решение.

Источники