Кратко

  • RFC 9892 — спецификация IETF на Standards Track. Она определяет расширяемый DLEP Traffic Classification Data Item с начальными Sub-Data Item для Diffserv и Ethernet.
  • TID обозначает локальный для модема набор классификации, а FID маркирует потоки внутри Sub-Data Item. Связь с назначением и практический смысл задаёт использующее расширение.
  • Полученный TID инициализирует или заменяет связанную информацию классификации. Сам RFC 9892 не задаёт планировщик, веса очередей, политику допуска или алгоритм credit-window.

Что именно происходит

Базовый DLEP идентифицирует конечные точки. RFC 9892 добавляет возможность сообщить маршрутизатору, как идентификаторы плоскости данных объединяются в потоки. Traffic Classification Identifier, или TID, — это имя набора классификации, локальное для модема. Его нельзя автоматически считать глобально уникальным или имеющим одинаковый смысл у разных модемов. Flow Identifier, или FID, обозначает поток внутри соответствующего Sub-Data Item.

Какой адресат связан с TID и какое действие должна выполнить система, определяет потребляющее согласованное расширение. RFC 9892 описывает перенос состояния, но не выбирает за расширение конкретную операцию в плоскости данных. При получении TID связанная информация классификации инициализируется либо заменяется. Маршрутизатор должен при необходимости обновить относящееся к ней состояние плоскости данных. Это следует понимать как замену набора, а не как разрешение незаметно смешивать старые и новые записи.

Diffserv Sub-Data Item группирует значения DSCP. Нулевое количество DSCP означает wildcard для значений, которые иначе не сопоставлены. Ethernet Sub-Data Item группирует значения VLAN/PCP; нулевое количество PCP задаёт совпадение по умолчанию. Повторение DS Field внутри одного Traffic Classification Data Item является ошибкой. Повторение приоритета внутри одного Data Item также является ошибкой. Проверка должна охватывать весь Data Item, а не только отдельный фрагмент приёма.

Если срабатывают оба типа классификации, приоритет принадлежит Ethernet VID/PCP, и используется TID этого Ethernet-сопоставления. В Ethernet явные VLAN-сопоставления проверяются раньше PCP по умолчанию. Поэтому wildcard или default не перекрывает явное совпадение. Это правило приоритета не означает, что DSCP вообще теряет значение; оно определяет конкретный конфликт классификаторов.

Граница ответственности

RFC 9892 не определяет планировщик, веса очередей, admission policy или алгоритм credit-window. RFC 9893 — пример расширения, связанного с управлением потоком через кредитное окно, но это не часть требований RFC 9892. Исходный набор также не подтверждает распространённость развёртываний, измеренную производительность или конкретную промышленную политику очередей.

Будущие типы классификаторов, например пятиэлементные кортежи, являются примерами расширяемости, а не определениями RFC 9892. Назначение TID и его операционный смысл остаются специфичными для расширения. Источники не устанавливают, что метки DSCP заслуживают сквозного доверия через административные домены. Наличие метки не превращает её в универсальное доказательство личности или полномочий.

Злонамеренный участник, изменяющий отображение классификации на очереди, может вызвать задержку, перегрузку или потери в классах обслуживания. RFC 9892 не создаёт новую сквозную модель доверия. Он указывает на применимые меры защиты транспорта DLEP или канального уровня в контексте RFC 8175 и самого RFC 9892. Нельзя превращать это указание в выдуманную гарантию end-to-end доверия.

Анализ Theo March

Следующие меры — анализ Theo March, а не требования RFC 9892. Оператору полезно вести журнал аудита, связывающий DLEP-сеанс и участника, время, TID, версию Data Item, результат проверки и потребляющее расширение. Для каждой замены нужен контрольный вариант с прежним состоянием и понятная процедура rollback. Старое состояние не следует повторно применять только потому, что его формат выглядит допустимым: нужно проверить сеанс, порядок и актуальность.

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

Операционный путь решения

  1. Убедиться, что согласовано расширение DLEP, которое требует и интерпретирует TID/FID; заранее зафиксировать назначение TID и его смысл.
  2. Проверить весь Data Item: отклонить повторяющиеся DS Field и приоритеты, корректно обработать wildcard и записать версию данных.
  3. Воспроизвести решение о совпадении: проверить DSCP и VLAN/PCP, при конфликте выбрать Ethernet VID/PCP и зафиксировать использованный TID.
  4. Определить фактическое действие расширения в плоскости данных. Не приписывать RFC 9892 веса очередей, планировщик или кредитное окно.
  5. Проверить защиту транспорта DLEP или канала и оценить границы доверия при переходе между доменами; не заявлять сквозную гарантию.
  6. При ошибке проверки или неожиданном эффекте вернуть последнюю подтверждённую версию и записать решение в журнале аудита.

Проверочные фикстуры

  • Diffserv: один FID содержит неповторяющиеся DSCP и нулевое количество DSCP. Ожидание: иначе не сопоставленные значения попадают в wildcard.
  • Отказ по дубликату: один DS Field дважды присутствует в Data Item. Ожидание: полная проверка отклоняет Data Item до фиксации набора.
  • Ethernet: заданы явные VLAN/PCP и PCP по умолчанию. Ожидание: сначала срабатывает явное значение, default используется только при отсутствии специального совпадения.
  • Приоритет: пакет одновременно соответствует DSCP и VLAN/PCP. Ожидание: побеждает Ethernet VID/PCP, а в журнале виден Ethernet TID.
  • Замена: под одним TID сначала передан набор A, затем набор B. Ожидание: B заменяет связанную информацию; не следует предполагать неописанное объединение.

Эти фикстуры проверяют границы протокола, но не доказывают производительность или конкретную политику планировщика.

Источники