Кратко

  • В draft-xiao-fann-fast-cnp-with-proxy-05 перегруженный узел сначала посылает UDP-уведомление прокси, а прокси строит второй пакет, понятный отправителю RoCEv2.
  • Полученный отправителем CNP может быть корректным и полезным, но не раскрывать версию отображения потока и QP, исходный узел перегрузки или уведомления, отброшенные локальной политикой прокси.

Отправитель получает обычный RoCEv2 Congestion Notification Packet и снижает скорость затронутой Queue Pair. С его стороны сигнал выглядит знакомо. Однако перегруженный маршрутизатор не отправлял ему стандартный CNP. Он послал другой UDP-пакет прокси. Тот обратился к состоянию, выученному из трафика, определил отправителя и Source QP, а затем создал пакет, который увидел хост.

Именно этот перевод описывает пятая редакция Fast Congestion Notification Packet with Proxy, опубликованная 29 сентября. Маршрутизатор VPN-провайдера может находиться не в том домене маршрутизации, где находится отправитель, и не иметь Source QP, необходимого для обычного RoCEv2 CNP. Прокси соединяет эти контексты.

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

Одно событие становится двумя пакетами

На первом участке перегруженный узел отправляет отдельное уведомление прокси в том же контролируемом домене. На втором прокси создает уведомление в формате, который уже поддерживает отправитель. Редакция 05 сужает описание до стандартного случая RoCEv2 и больше не обещает универсального перевода для любого транспорта.

Формат 1 переносит IP-пятерку потока и 24-битный Destination QP на предлагаемый UDP-порт TBD1. По адресу источника прокси находит отправителя, а по протоколу и порту назначения распознает RoCEv2. Для стандартного CNP ему еще нужен Source QP, поэтому он обращается к отображению Source-QP/Destination-QP в контексте адресов источника и назначения.

Это отображение не сводится к конфигурации. Выбранный прокси должен видеть прямой и обратный трафик RoCEv2, чтобы выучить связь. В первом уведомлении есть Destination QP, но нет готового Source QP. Следовательно, перевод зависит от сохраненного состояния наблюдений.

Формат 2 переносит ту же пятерку и NRP Selector ID на другой предлагаемый порт, TBD2. В случае RoCEv2 селектор помогает найти Source QP; в случае VPN — определить VPN. Прокси требуются отображения Source-QP/NRP или VPN-ID/NRP. Селектор служит ключом поиска, а не доказательством свежести таблицы.

Объявленная способность не равна текущему состоянию

Узлу перегрузки сначала нужно узнать, какой прокси обслуживает префикс отправителя. Проект предлагает объявлять Proxy Node Capability, PNC, вместе с префиксами подключенных отправителей. Для IS-IS и OSPF предусмотрены P-флаги, для BGP — предлагаемый Next Hop Dependent Characteristic TLV с адресом прокси.

Эти сигналы отвечают на вопрос маршрутизации: какой узел заявляет сервис прокси для данного префикса? Они не показывают, видел ли он оба направления трафика, выучил ли правильную пару QP, сохранил ли актуальную связь NRP или VPN, имеет ли запас ограничителя, принял ли первое уведомление и доставил ли второе.

Объявление может оставаться неизменным, пока выученное состояние стареет, перемещается или конфликтует. Распространившийся бит способности не является проверкой здоровья таблиц за ним.

Прокси вправе намеренно удалить часть свидетельств

В обычном случае прокси должен посылать второе уведомление на каждое принятое первое. Но текст сразу вводит исключение: если частота входящих сообщений превышает локальный предел, прокси может отбрасывать часть из них по своей политике.

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

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

У молчания много объяснений: перегрузки не было, выбран неверный прокси, маршрут PNC устарел, отображение отсутствует, сработал пограничный фильтр, функция выключена, первое сообщение ограничено по частоте или второе потерялось. Формат на проводе не различает эти случаи.

Полезный CNP — еще не квитанция происхождения

Это не значит, что переведенная команда ложна. Она может сообщать ровно то, что требуется старому отправителю: снизить скорость восстановленной Source QP. Ценность совместимости в том, что конечную систему не нужно немедленно учить новому первому формату.

Ошибка начинается, когда совместимый пакет принимают за подтверждение происхождения. Синтаксис UDP и checksum не аутентифицируют исходное событие. Итоговый CNP не показывает байты первого сообщения или время его приема прокси, не считает все события, не локализует узкое место и не доказывает, что таблица выбрала нужный поток.

Операторам нужна связанная цепочка. В точке перегрузки следует хранить счетчики очереди и ECN, число первых сообщений и выбранный прокси. В маршрутизации — точный маршрут PNC на момент события. На прокси — поколение отображения, время обучения, число принятых и отброшенных сообщений, основание перевода и количество выпущенных CNP. У отправителя — принятые CNP, реакцию QP и изменение скорости. Независимые показатели восстановления очереди, времени завершения и эффекта приложения завершают проверку.

Ни одна запись не дает всей картины. Доказательством становится их сопоставление.

Редакция 05 также ограничивает уровень зрелости

Новая версия убирает широкие формулировки о произвольных не-RoCE отправителях и точнее описывает стандартное построение RoCEv2 CNP. Она прямо говорит, что для изучения связи Source-QP/Destination-QP прокси должен находиться на прямом и обратном пути. Также упомянут вариант, в котором на вход прокси подают пакет данных с меткой ECN, но этот метод оставлен за рамками документа.

Это не определенный третий формат и не отчет о совместимости реализаций. Документ остается индивидуальным Internet-Draft без stream, ответственного AD или формального статуса IETF. Порты, флаги протоколов маршрутизации и код характеристики BGP остаются предложениями. Описанный пакет сам по себе не доказывает внедрение, производительность или наличие названной совместимой реализации.

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

Источники