Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 10052 Ciena Corporation
Category: Standards Track E. Ruffini
ISSN: 2070-1721 OutSys
H. Nydell
Cisco Systems
R. Foote
Nokia
W. Hawkins
University of Cincinnati
September 2026
Performance Measurement with Asymmetrical Traffic Using the Simple Two-Way Active Measurement Protocol (STAMP)
Измерение производительности по протоколу STAMP с асимметричным трафиком
Аннотация
Этот документ задаёт необязательное расширение простого протокола активных двухсторонних измерений (Simple Two-way Active Measurement Protocol или STAMP), позволяющее Session-Reflector передавать асимметричные пакеты, т. е. пакеты откликов, размер или число которых отличается от переданных Session-Sender. Хотя стандартные обмены STAMP симметричны, в некоторых случаях измерения можно выполнить более точно при отражении пакетов другого размера или отправке дополнительных откликов. Расширение задаёт TLV управления отражёнными тестовыми пакетами и связанные с ним процедуры, анализирует проблемы при активном измерении (включая групповые среды) и описывает поведение STAMP для повышения эффективности измерений и снижения влияния на сеть.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc10052.
Авторские права
Авторские права (Copyright (c) 2026) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с пересмотренной лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Revised BSD License).
1. Введение
Простой протокол двухсторонних активных измерений (STAMP) [RFC8762] определяет базовую функциональность STAMP. Необязательные расширения STAMP [RFC8972] включают структуру TLV, позволяющую Session-Sender включать дополнительные инструкции для Session-Reflector с целью расширения базовой функциональности протокола STAMP. Могут быть заданы новые STAMP TLV для поддержки сценариев, подобных описанным в [RFC7497], где рассмотрена координация сообщений между источником и получателем, помогающая реализовать один из фундаментальных принципов измерений производительности IP, минимизируя влияние тестового трафика на потоки пользователей.
По умолчанию Session-Sender и Session-Reflector обмениваются пакетами симметрично — число пакетов, которые передают Session-Reflector и Session-Sender, а также их размеры одинаковы. Однако в некоторых случаях, например, при измерении скорости, рассмотренном в [RFC7497], было бы полезно, чтобы Session-Reflector передавал тестовые пакеты асимметрично, т. е. их размер отличался бы от размера тестовых пакетов Session-Sender, и/или пакеты не передавались бы как непосредственные отклики на пакеты от Session-Sender. Расширение, заданное в этом документе, предоставляет инструменты для создания такой асимметрии пакетов между Session-Sender и Session-Reflector.
Измерение показателей производительности в сети с групповой передачей (multicast) с применением активного метода (параграф 3.4 в [RFC7799]) сложнее измерений в сети с индивидуальным трафиком (unicast). В документе анализируются эти сложности, а также заданы процедуры и расширения STAMP для более эффективных измерений с меньшим воздействием на сеть.
2. Используемые соглашения
2.1. Термины
В документе применяются термины, заданные в [RFC8762], в частности, Session-Sender, Session-Reflector, «симметричные пакеты», термины из [RFC8972], в частности, STAMP Session Identifier (SSID), STAMP TLV Flag, Sub-TLV, а также термины из [RFC7497], в частности, In-Service и Out-of-Service.
В документе термин «асимметричные пакеты» имеет двоякий смысл в зависимости от контекста. Первым аспектом асимметрии является различие размера пакетов, передаваемых Session-Reflector, и пакетов, получаемых им от Session-Sender. Вторым аспектом является число пакетов, которые Session-Reflector передаёт в ответ на один пакет STAMP-Test.
Групповой (multicast) сетью в этом документе называется модель коммуникационной сети, где отправитель передаёт один пакет, адресованный multicast-группе, и сеть доставляет копию этого пакета каждому участнику группы.
2.2. Сокращения
CE
Congestion Experienced — возникла перегрузка.
ECN
Explicit Congestion Notification — явное уведомление о перегрузке.
EUI
Extended Unique Identifier — расширенный уникальные идентификатор.
MAC
Media Access Control — управление доступом к среде.
STAMP
Simple Two-way Active Measurement Protocol — простой протокол активных двухсторонних измерений.
TLV
Type-Length-Value — тип, размер, значение.
2.3. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
3. Reflected Test Packet Control TLV
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAMP TLV Flags| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length of the Reflected Packet |Number of the Reflected Packets| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interval Between the Reflected Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub-TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 1. Формат Reflected Test Packet Control TLV.
В этом параграфе задано необязательное расширение STAMP для управления отражёнными тестовыми пакетами (Reflected Test Packet Control TLV) и дополнительный битовый флаг в поле STAMP TLV Flags. Формат TLV показан на рисунке 1.
STAMP TLV Flags
1-октетное поле флагов [RFC8972].
Type
1-октетное поле, указывающее Reflected Test Packet Control TLV. Поле имеет значение 12 (параграф 6.1).
Length
2-октетное поле размера с переменным значением, в котором недопустимы значения меньше 12.
Length of the Reflected Packet
2-октетное поле (целое число без знака) запрошенного размера тестовых пакетов в октетах.
Number of the Reflected Packets
2-октетное поле (целое число без знака), указывающее число отражённых тестовых пакетов, которые Session-Reflector просит передавать в ответ на получение пакета STAMP-Test с Reflected Test Packet Control TLV.
Interval Between the Reflected Packets
4-октетное поле (целое число без знака), указывающее интервал (в наносекундах) между отправкой последовательных отражённых тестовых пакетов в ответ на пакет STAMP-Test с Reflected Test Packet Control TLV.
Sub-TLVs
Необязательное поле с дополнительной информацией от Session-Sender.
Агентство IANA выделило дополнительный флаг STAMP TLV [RFC8972] (Conformant Reflected Packet) в реестре STAMP TLV Flags (параграф 6.2) — бит C (3). Session-Sender должен сбрасывать (0) этот флаг при передаче, а Session-Reflector должен игнорировать флаг при получении пакета STAMP-Test со STAMP TLV.
Session-Sender может включать Reflected Test Packet Control TLV в тестовые пакеты STAMP. При получении STAMP-Test с Reflected Test Packet Control TLV Session-Reflector должен передать последовательность отражённых тестовых пакетов в соответствии с указанными ниже правилами.
-
Размер отражённых тестовых пакетов должен быть большим из двух значений, указанных ниже.
-
-
Размер базового пакета Session-Reflector (аутентифицированного или неаутентифицированного), соответствующий полученному пакету STAMP-Test, как указано в параграфе 4.3 [RFC8762], включая все TLV расширений STAMP [RFC8972], присутствующие в полученном пакете STAMP-Test, но не включая Extra Padding TLV (основанием для исключения Extra Padding TLV, присутствующих вместе с Reflected Test Packet Control TLV, является необходимость поддержки сценария, в котором просят Session-Reflector передавать последовательность пакетов, которые короче принятого пакета STAMP).
-
Значение поля Length of the Reflected Packet в Reflected Test Packet Control TLV с выравниванием по 4-октетной границе.
-
В случае, когда рассчитанный по этому правилу размер отражённого пакета больше, чем размер, полученный по правилам из раздела 4 в [RFC8972], Session-Reflector должен использовать Extra Padding TLV (параграф 4.1 в [RFC8972]) для увеличения размера отражённого пакета. Если рассчитанный размер превышает максимальный размер передаваемого блока (maximum transmission unit или MTU) на интерфейсе в сторону Session-Sender, Session-Reflector должен установить (1) флаг Conformant Reflected Packet STAMP TLV (параграф 6.2) и передать 1 отражённый пакет с размером MTU на выходном интерфейсе. В иных случаях Session-Reflector должен сбрасывать (0) флаг в каждом отражённом тестовом пакете.
Число отражённых пакетов в последовательности должно быть равно значению поля Number of the Reflected Packets.
Если значение поля Number of the Reflected Packets больше 1, интервал между двумя последовательными отражёнными пакетами должен быть равен значению поля Interval Between the Reflected Packets (в наносекундах). Для предотвращения перегрузки, вызываемой отражёнными пакетами, Session-Reflector с поддержкой Reflected Test Packet Control TLV должен ограничивать скорость (в байт/сек.) и общий размер (в байтах) содержимого пакетов STAMP, генерируемых в ответ на входящий тестовый пакет. Если получен тестовый пакет, вызывающий генерацию сверх этих пределов, Session-Reflector должен установить (1) флаг C (параграф 6.2) и передать 1 отражённый пакет, размер которого определён приведёнными выше правилами. В иных случаях Session-Reflector должен сбрасывать (0) флаг в каждом отражённом тестовом пакете.
Если поле Number of the Reflected Packets имеет значение 0, рефлектору (Session-Reflector) недопустимо передавать отражённые пакеты. Кроме того, в таких случаях ему следует отбросить полученный пакет STAMP-Test. Однако локальные правила могут переопределять это заданное по умолчанию поведение и указывать иную обработку. Отметим, что такое поведение Session-Reflector наблюдается, когда поле Control Code Flags в суб-TLV Return Path Control Code (параграф 4.1.1 of [RFC9503]) имеет значение No Reply Requested. Если предполагается такое поведение, предпочтительно использовать Return Path TLV.
Каждый отражённый пакет в последовательности формируется в соответствии с параграфом 4.3 в [RFC8762].
Как отмечено выше, Session-Reflector будет устанавливать флаг C в отражённых пакетах в двух случаях. Для устранения неоднозначности условий установки (1) флага C реализация Session-Sender может задать две причины:
-
если размер полученного отражённого пакета STAMP меньше значения поля Length of the Reflected Packet, запрошенный размер превышает значение MTU на выходном интерфейсе Session-Reflector;
-
если размер полученного отражённого пакета STAMP равен значению поля Length of the Reflected Packet, запрошенная скорость и/или объем передаваемых данных превышает заданные Session-Reflector пределы.
3.1. Суб-TLV Address Group
Сеть с групповой передачей (multicast), использующая активное измерение производительности для оценки скорости обслуживания (In-Service), должна обеспечивать механизм управления скоростью, который ограничивает и регулирует создание измерительных пакетов. Поскольку групповая репликация может усиливать тестовый трафик в дереве распространения, неконтролируемая передача тестовых пакетов может приводить к перегрузке, изменять асимметрию трафика или иным способом нарушать условия измерений. Механизм контроля скорости должен обеспечивать предсказуемость трафика, а также его согласованность с рабочими характеристиками multicast-топологии. Согласование генерации тестовых пакетов с семантикой времени создания и выбора пакетов метода асимметричных измерений позволяет сохранить достоверность и сопоставимость собранных получателями сведений. Для внедрения в сетях с разными характеристиками (задержки, пропускная способность и т. п.) реализациям следует предоставлять оператору возможность задания ограничений скорости и параметров отправки, которые предотвратят чрезмерную или неравномерную репликацию тестовых пакетов, сохраняя статистически значимые выборки измерений.
3.1.1. Layer 2 Address Group Sub-TLV
Необязательный суб-TLV Layer 2 Address Group с переменным размером включает поля Layer 2 Address Group Mask и Address Group, используемые Session-Sender при выборе Session-Reflector для откликов. Суб-TLV может передавать расширенные уникальные идентификаторы (Extended Unique Identifier) EUI-48 и EUI-64 [IEEE-802.3-2022], а также 16-битовые короткие адреса для локальной идентификации в рамках персональной сети (Personal Area Network или PAN) [IEEE-802.15.4-2024]. Формат суб-TLV Layer 2 Address Group показан на рисунке 2.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-TLV Flags| Sub-TLV Type | Sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Layer 2 Address Group Mask (переменный размер) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Layer 2 Address Group (переменный размер) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 2. Формат Layer 2 Address Group Sub-TLV.
Sub-TLV Flags
8-битовое поле флагов, формат, значения и интерпретация которых заданы для STAMP TLV Flags в [RFC8972]. Значения флагов берутся из реестра STAMP TLV Flags [IANA-STAMP].
Sub-TLV Type
1 -октетное поле с выделенным IANA значением 10 (параграф 6.3).
Sub-TLV Length
2-октетное поле, значение которого указывает число октетов Layer 2 Address Group sub-TLV. Поскольку размеры полей Layer 2 Address Group Mask и Layer 2 Address Group должны совпадать, действительными значениями поля Sub-TLV Length являются 4, 12 и 16. При иных значениях Session-Reflector должен считать суб-TLV некорректно сформированным.
Поле Value в Layer 2 Address Group sub-TLV состоит из двух полей.
Layer 2 Address Group Mask
Битовая маска, применяемая ко всем MAC, связанным с Session-Reflector. Размер этого поля составляет 1/2 от значения поля Sub-TLV Length.
Layer 2 Address Group
Группа, котрой адресуется этот TLV. Размер этого поля составляет 1/2 от значения поля Sub-TLV Length.
Если Session-Reflector применяет значение поля Layer 2 Address Group Mask (побитовая операция AND — И) к любому из своих MAC-адресов того же размера и результат равен значению поля Layer 2 Address Group, Session-Reflector должен прекратить обработку Layer 2 Address Group Sub-TLV и продолжить обработку полученного тестового пакета. Если совпадения не найдено, Session-Reflector должен прекратить обработку принятого пакета.
3.1.2. Layer 3 Address Group Sub-TLV
Необязательный суб-TLV Layer 3 Address Group с переменным размером включает поля IP Prefix и Prefix Length, используемые Session-Sender при выборе Session-Reflector для откликов. Формат Layer 3 Address Group sub-TLV показан на рисунке 3.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Flags | Sub-TLV Type | Sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 4. Формат Layer 3 Address Group Sub-TLV.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Flags | Sub-TLV Type | Sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 3. Формат Layer 3 Address Group Sub-TLV.
Sub-TLV Flags
8-битовое поле флагов, формат, значения и интерпретация которых заданы для STAMP TLV Flags в [RFC8972]. Значения флагов берутся из реестра STAMP TLV Flags [IANA-STAMP].
Sub-TLV Type
1 -октетное поле с выделенным IANA значением 11 (параграф 6.3).
Sub-TLV Length
2-октетное поле со значением 8 (если IP Prefix указывает префикс адреса IPv4) или 20 (IP Prefix — префикс адреса IPv6). При иных значениях Session-Reflector должен считать суб-TLV некорректно сформированным.
Поле Value в Layer 3 Address Group Sub-TLV состоит из трёх полей.
Prefix Length
1-октетное целое число без знака, указывающее число битов значения префикса в поле IP Prefix.
Reserved
3-октетное резервное поле, которое должно устанавливаться в 0 при передаче и игнорироваться при получении.
IP Prefix
Поле переменного размера — 4 октета для префикса адреса IPv4 или 16 для префикса адреса IPv6.
При обработке этого суб-TLV Session-Reflector создаёт маску IP в соответствии со значением n в поле Prefix Length. Маской будет адрес IP (из семейства, указанного значением поля Sub-TLV Length, в соответствии с указанной выше семантикой), где n старших битов имеют значение 1, а остальные — 0. Если Session-Reflector применяет эту маску (побитовая операция AND — И) к любому IP-адресу из того же семейства и получает значение поля IP Prefix, он должен прекратить обработку Layer 3 Address Group Sub-TLV и продолжить обработку полученного тестового пакета. Если совпадения не найдено, Session-Reflector должен прекратить обработку принятого пакета.
4. Вопросы эксплуатации
4.1. Измерение скорости
В [RFC7497] определена задача измерения скорости доступа в сетях доступа. Одним из важных требований к протоколу тестирования является способность управлять на тестовом пути такими характеристиками пакетов, как асимметрия скорости и размера. Reflected Test Packet Control TLV (раздел 3) соответствует требованиям к измерению скорости доступа, обеспечивая элементы управления числом отражённых тестовых пакетов, из размером и временным интервалом, т. е. скоростью передачи последовательности отражённых тестовых пакетов. Показатели скорости доступа и метод их измерения выходят за рамки этого документа. UDP Speed Test (см. [RFC9097] и [RFC9946]) также позволяет измерить пропускную способность доступа.
4.1.1. Эксплуатационные вопросы при измерении скорости
Общие рекомендации по использованию тестового протокола для измерения скорости описаны в разделе 7 [RFC7497]. Эти рекомендации относятся к измерению скорости в рабочем (In-Service) и особом (Out-of-Service) режиме. При тестировании в режиме Out-of-Service оператор может задать очень высокую скорость и/или объем трафика (т. е. большие значения Length of the Reflected Packet и/или Number of the Reflected Packet для отражённых пакетов, а также небольшое значение поля Interval Between the Reflected Packets в Reflected Test Packet Control TLV) для создания перегрузки в узком месте. При тестировании в режиме In-Service оператор может начать с малой скорости и/или объёма трафика, постепенно повышая их в каждом переданном Reflected Test Packet Control TLV.
Клиенту, выполняющему обширные измерения скорости в работающей сети, следует соблюдать п. 6 из раздела 11 в [RFC9946] и помнить об ограничениях услуги, заданных сервис-провайдером. В частности, активные измерения могут создавать большой объем данных, способный привести к нарушению тестирующей стороной соглашения об уровне обслуживания, заключённого с поставщиком услуг.
4.2. Активное измерение производительности в multicast-среде
Для измерения производительности с использованием STAMP в среде с групповой передаче предполагается, что Session-Sender является корнем дерева группового распространения, а рефлекторы Session-Reflector — листьями. Механизм построения дерева выходит за рамки документа.
Согласно [RFC8972], Session-Reflector демультиплексирует сессию STAMP с помощью кортежа, состоящего из IP-адресов и портов UDP отправителя и получателя или IP-адреса источника и идентификатора сессии STAMP. Это происходит и при измерении производительности группового потока, несмотря на групповой адрес получателя. Поэтому для Session-Reflector не задаётся специального поведения при получении пакетов STAMP-Test через групповое дерево и пакеты обрабатываются в соответствии с [RFC8762] и [RFC8972]. Session-Reflector должен использовать IP-адрес источника в полученном пакете STAMP-Test как адрес получателя отражённого тестового пакета и должен использовать один из IP-адресов своего узла в качестве адреса отправителя такого пакета. В результате Session-Sender может получать отклики от множества Session-Reflector. Такой Session-Sender может включать в пакеты Reflected Test Packet Control TLV с суб-TLV Layer 2 Address Group или Layer 3 Address Group для ограничения числа отражающих пакеты Session-Reflector.
Саму multicast-среду можно настроить для снижения вероятности перегрузки сети, если один пакет создаёт большое число одновременных откликов, направленных в одну конечную точку. В зависимости от реализации групповой передачи добавление Reflected Test Packet Control TLV может позволить групповой среде ограничивать число откликов путём изменения значений суб-TLV в Reflected Test Packet Control TLV любых пакетов, которые среда видит, разрешая передачу откликов лишь рефлекторам которые:
-
выбраны случайно заданием Layer 2 Address Group sub-TLV, например, установкой в EUI-48 Address Group Mask значения 0xF и EUI-48 Address Group 0x1; в результате отвечать будет лишь 1 рефлектор из 16;
-
размещены на конкретном сетевом адаптере, путём задания Layer 2 Address Group sub-TLV с EUI-48 Address Group Mask 0xFFFFFF000000;
-
относятся к конкретным сетям IP, например, к подсети, выделенной для инкапсуляции IPv6-over-IPv4, путём задания соответствующего Layer 3 Address Group sub-TLV.
Групповой трафик асимметричен по своей природе. Восходящее направление (от источника к получателям) обычно доминирует, а обратному пути уделяется ограниченное внимание, поскольку групповая передача происходит в основном от одного ко многим и создаёт сравнительно небольшой нисходящий трафик в обратном направлении. Значение поля Length of the Reflected Packet можно использовать для того, чтобы отражённый пакет содержал все метки времени и запрошенную информацию, которые нужны для измерений, но был как можно короче, чтобы не перегружать сеть ненужными данными.
4.3. Применение Reflected Test Packet Control TLV в сочетании с другими TLV
В [RFC9503] задан Return Path TLV, который в сочетании с Return Address Sub-TLV позволяет Session-Sender запросить отправку отражённого пакета по адресу, отличному от адреса Session-Sender. Эти расширения STAMP можно применить вместе с заданным здесь Reflected Test Packet Control TLV, чтобы направить отражённые пакеты STAMP-Test в коллектор измерительных данных (см. [RFC7594]) для дальнейшей обработки и сетевой аналитики. Примером такого использования является групповая передача, когда, например, Session-Sender находится вблизи фактического источника multicast-пакетов (например, камеры, передающей видео «вживую») и тестовые пакеты следуют по тому же пути, что и пакеты видео-потока, а отражённые направляются другому получателю для анализа.
Для совместимости [RFC9503] отправителю Session-Sender недопустимо включать Return Path Control Code sub-TLV со значением No Reply Requested в Control Code Flags тестовых пакетов, включающих Reflected Test Packet Control TLV с ненулевым значением. Session-Reflector с поддержкой обоих TLV должен устанавливать (1) флаг U в TLV Return Path и Reflected Test Packet Control отражённых пакетов STAMP. Рефлектору Session-Reflector следует регистрировать уведомление, сообщающее оператору о некорректном пакете STAMP.
Reflected Test Packet Control TLV можно применять вместе с Class of Service TLV [RFC8972] для повышения эффективности тестирования скорости в multicast-сети с отслеживанием согласованности кодов дифференцированного обслуживания (Differentiated Services Code Point или DSCP) и значений ECN в прямом и обратном направлении конкретной сессии STAMP-Test.
5. Вопросы безопасности
Вопросы безопасности, рассмотренные в [RFC7497], [RFC8762], [RFC8972] и [RFC9503], применимы к этому документу. Поддельные пакеты STAMP-Test с Reflected Test Packet Control TLV могут служить для организации отказов в обслуживании (Denial-of-Service или DoS). Поэтому реализации должны использовать механизм защиты отождествления (identity). Например, Session-Reflector может проверять сведения об источнике пакета STAMP по заранее заданному списку доверенных узлов. Реализации с поддержкой этой спецификации должны обеспечивать административный контроль использования Reflected Test Packet Control TLV на Session-Reflector и его запрет по умолчанию. Следует также применять режим аутентификации STAMP [RFC8762] или HMAC (Hashed Message Authentication Code) TLV [RFC8972] для сессий STAMP-Test, включающих Reflected Test Packet Control TLV. Отметим, что при включённой защите целостности любые изменения пакетов в пути будут приводить к отказу при проверке, если только изменяющий элемент не находится в границах доверия и может пересчитать контрольную сумму целостности.
Кроме того, DoS-атака с применением Reflected Test Packet Control TLV может быть нацелена на STAMP Session-Reflector, вызывая перегрузку отражёнными пакетами за счёт задания небольших интервалов и/или чрезмерного числа одновременных тестовых сессий. Для смягчения этого реализации Session-Reflector с поддержкой нового TLV должны обеспечивать механизм ограничения скорости и объёма пакетов STAMP-Test (см. обсуждение в разделе 3).
С учётом возможного числа отражённых пакетов в ответ на один тестовый пакет, переданный по групповому адресу, параметры в первом пакете STAMP-Test с Reflected Test Packet Control TLV должны выбираться консервативно. Рассмотрим значение 1 в поле Number of the Reflected Packets. В результате такой установки Session-Sender, учтя число пакетов после отправки первого пакета STAMP-Test с Reflected Test Packet Control TLV, может оценить нагрузку, вызванную использованием Reflected Test Packet Control TLV, где запрошено более 1 отражённого пакета от рефлектора в ответ на отправленный по групповому адресу тестовый пакет. Для дальнейшего смягчения риска при использовании Reflected Test Packet Control TLV в multicast-сети отправителю (Session-Sender) следует подписывать пакеты с использованием HMAC TLV при передаче в режиме без аутентификации [RFC8762]. Однако даже при наличии HMAC TLV можно использовать Reflected Test Packet Control TLV для атак с воспроизведением (replay). Для снижения этого риска рефлекторам STAMP (Session-Reflector) следует использовать значение поля Sequence Number [RFC8762] из полученного пакета STAMP-Test. Если при сравнении этого значения с номером из предыдущего тестового пакета той же сессии STAMP-Test не наблюдается монотонного роста, Session-Reflector должен отвечать одним отражённым пакетом, установив (1) флаг U [RFC8972]. Это может не указывать replay-атаку, а говорить о нарушении порядка или дублировании пакетов в сети. Оператор может использовать иные методы диагностики для идентификации и локализации проблемы. Реализация Session-Reflector может использовать арифметику порядковых номеров (Serial Number Arithmetic) [RFC1982] или другие методы проверки корректности порядка доставки тестовых пакетов.
Отправителю Session-Sender не следует передавать следующий пакет STAMP-Test с Reflected Test Packet Control TLV до ожидаемого завершения передачи рефлектором всех отражённых пакетов в ответ на Reflected Test Packet Control TLV в предыдущем тестовом пакете. В некоторых случаях Reflected Test Packet Control TLV может вызывать перегрузку в узких местах. Требования защиты при измерении производительности с несимметричным трафиком UDP заданы в разделе 10 [RFC9097].
При планировании измерений пропускной способности в рабочем режиме (In-Service) операторам следует выполнять рекомендации разделов 3 и 7 в [RFC7497]. Если базовая сеть поддерживает ECN, Session-Reflector может получать пакеты STAMP-Test с полем ECN, содержащим маркер перегрузки (Congestion Experienced или CE). Это маркировка ECN указывает начало перегрузки, а не потерю пакетов, однако интерпретация того, что считать значительной перегрузкой (significant congestion) и пороговые значения реакции на ECN-CE зависит от конкретного развёртывания, целей услуги и политики оператора. Операторам следует понимать, что измерения пропускной способности в режиме In-Service могут влиять на условия перегрузки в сети и вносить вклад в маркировку ECN-CE. Реализациям и рабочим процедурам следует гарантировать, что использование STAMP для измерений в рабочем режиме не может приводить к непреднамеренной деградации трафика данных или ошибочной интерпретации сигналов ECN, связанных с перегрузкой. Пороговые значения и способы смягчения перегрузки зависят от конкретной системы и их следует задавать в соответствии с политикой оператора и целями сети в части производительности.
В параграфе 3.1.5 [RFC8085] указано, что механизму контроля перегрузок UDP следует отвечать на возникновение перегрузки и учитывать долю потерь и время отклика при выборе нового значения скорости. В параграфе 8.1 [RFC9097] приведён алгоритм регулировки скорости с примером псевдокода в Приложении A к [RFC9097].
6. Взаимодействие с IANA
6.1. Тип Reflected Test Packet Control TLV
Агентство IANA выделило значение для Reflected Test Packet Control TLV в реестре STAMP TLV Types группы Simple Two-way Active Measurement Protocol (STAMP) TLV Types, как указано в таблице 1.
Таблица 1. Тип Reflected Test Packet Control TLV.
|
Значение |
Описание |
Документ |
|---|---|---|
|
12 |
Управление отражёнными тестовыми пакетами |
RFC 10052 |
6.2. Флаг Conformant Reflected Packet STAMP TLV
Агентство IANA выделило битовую позицию для флага Conformant Reflected Packet STAMP TLV в реестре STAMP TLV Flags группы Simple Two-way Active Measurement Protocol (STAMP) TLV Types, как указано в таблице 2.
Таблица 2. Флаг Conformant Reflected Packet STAMP TLV.
|
Позиция бита |
Символ |
Описание |
Документ |
|---|---|---|---|
|
3 |
C |
Согласование |
RFC 10052 |
6.3. Типы Layer 2 и Layer 3 Address Group Sub-TLV
Агентство IANA выделило значения для типов суб-TLV Layer 2 Address Group и Layer 3 Address Group в реестре STAMP Sub-TLV Types группы Simple Two-way Active Measurement Protocol (STAMP) TLV Types, указанные в таблице 3.
Таблица 3. Типы STAMP Sub-TLV Reflected Test Packet Control TLV.
|
Значение |
Описание |
Используется с TLV |
Документ |
|---|---|---|---|
|
10 |
Группа адресов L2 |
Reflected Test Packet Control |
RFC 10052 |
|
11 |
Группа адресов L3 |
Reflected Test Packet Control |
RFC 10052 |
7. Литература
7.1. Нормативные документы
[IANA-STAMP] IANA, «STAMP Sub-TLV Types», <https://www.iana.org/assignments/stamp-tlv-types>.
[RFC1982] Elz, R. and R. Bush, «Serial Number Arithmetic», RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC7497] Morton, A., «Rate Measurement Test Protocol Problem Statement and Requirements», RFC 7497, DOI 10.17487/RFC7497, April 2015, <https://www.rfc-editor.org/info/rfc7497>.
[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, «Simple Two-Way Active Measurement Protocol», RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, «Simple Two-Way Active Measurement Protocol Optional Extensions», RFC 8972, DOI 10.17487/RFC8972, January 2021, <https://www.rfc-editor.org/info/rfc8972>.
[RFC9503] Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and R. Foote, «Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks», RFC 9503, DOI 10.17487/RFC9503, October 2023, <https://www.rfc-editor.org/info/rfc9503>.
[RFC9946] Morton, A., Ciavattone, L., and R. Geib, Ed., «The UDP Speed Test Protocol (UDPSTP) for One-Way IP Capacity Metric Measurement», RFC 9946, DOI 10.17487/RFC9946, April 2026, <https://www.rfc-editor.org/info/rfc9946>.
7.2. Дополнительная литература
[IEEE-802.3-2022] IEEE, «IEEE Standard for Ethernet», IEEE Std 802.3-2022, DOI 10.1109/IEEESTD.2022.9844436, July 2022, <https://doi.org/10.1109/IEEESTD.2022.9844436>.
[IEEE-802.15.4-2024] IEEE, «IEEE Standard for Low-Rate Wireless Networks», IEEE Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632, December 2024, <https://doi.org/10.1109/IEEESTD.2024.10794632>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, «A Framework for Large-Scale Measurement of Broadband Performance (LMAP)», RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.
[RFC7799] Morton, A., «Active and Passive Metrics and Methods (with Hybrid Types In-Between)», RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, «UDP Usage Guidelines», BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC9097] Morton, A., Geib, R., and L. Ciavattone, «Metrics and Methods for One-Way IP Capacity», RFC 9097, DOI 10.17487/RFC9097, November 2021, <https://www.rfc-editor.org/info/rfc9097>.
Благодарности
Авторы благодарны Zhang Li, Ruediger Geib, Rakesh Gandhi, Giuseppe Fioccola, Xiao Min, Greg White и Rohan Bhosle за тщательное рецензирования и полезные приложения, которые улучшили документ.
Адреса авторов
Greg Mirsky
Ciena Corporation
Email: gregimirsky@gmail.com
Ernesto Ruffini
OutSys
Email: eruffini@outsys.org
Henrik Nydell
Cisco Systems
Email: hnydell@cisco.com
Richard Foote
Nokia
Email: footer.foote@nokia.com
Will Hawkins
University of Cincinnati
Email: hawkinsw@obs.cr
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.