Internet Engineering Task Force (IETF) G. Fioccola, Ed.
Request for Comments: 9341 Huawei Technologies
Obsoletes: 8321 M. Cociglio
Category: Standards Track Telecom Italia
ISSN: 2070-1721 G. Mirsky
Ericsson
T. Mizrahi
T. Zhou
Huawei Technologies
December 2022
Alternate-Marking Method
Метод чередующейся маркировки
Аннотация
В этом документе описан метод чередующейся маркировки (Alternate-Marking) для измерения потери пакетов, задержки и её вариаций на реальном трафике. Метод применим в разных ситуациях и для разных протоколов. В соответствии с классификацией RFC 7799 метод можно считать пассивным или гибридным в зависимости от варианта применения. Документ отменяет RFC 8321.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительные сведения о документах Internet Standard приведены в разделе 2 RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9341.
Авторские права
Авторские права (Copyright (c) 2022) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с пересмотренной лицензией BSD (Revised BSD License), как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Revised BSD License).
1. Введение
В сетях большинства сервис-провайдеров передаётся трафик, содержимое которого крайне чувствительно к потере пакетов [RFC7680], задержкам [RFC7679] и их вариациям [RFC3393]. Поэтому нужны методики и инструменты мониторинга и точного измерения производительности сети для постоянного контроля качества обслуживания с точки зрения конечных пользователей. Мониторинг производительности также даёт полезные сведения для управления сетью (например, для изоляции проблем в сети, устранения неполадок и т. п.).
В [RFC7799] определены активные, пассивные и гибридные методы измерений. Активные методы зависят от специального потока измерительных пакетов, пассивные основаны исключительно на наблюдениях ненарушаемого и неизменного потока интересующих пакетов, а в гибридных методах применяется сочетание этих вариантов.
В этом документе предложен метод мониторинга производительности, названный «методом чередующейся маркировки» (Alternate-Marking Method) который потенциально подходит для любого пакетного трафика (индивидуального и группового), включая Ethernet, IP и MPLS. Метод предназначен в первую очередь для измерения потерь пакетов, но его легко расширить для измерения односторонней или двухсторонней задержки и её вариаций.
Описанный в документе метод чередующейся маркировки позволяет синхронизировать измерения в разных точках путём разбиения потока пакетов на блоки (batch). Таким образом, можно получить согласованные счётчики и метки времени в каждом интервале маркировки и, следовательно, измерить показатели производительности потока.
Метод был разработан специально для пассивных и гибридных измерений, как указано в [RFC8321]. Однако, в соответствии с определениями [RFC7799], его можно отнести к гибридным измерениям типа I (Hybrid Type I). Чередующаяся маркировка может быть реализована с использованием резервных битов в заголовках пакетов, а изменение значений битов маркеров на границах доменов (а не на пути) формально является изменением интересующего потока.
Следует отметить, что этот документ описывает методологию, а механизмы, которые могут применяться для передачи значений счётчиков и временных меток выходят за рамки документа. Дополнительные сведения о применимости метода чередующейся маркировки приведены в [IEEE-NETWORK-PNPM].
1.1. Сводка отличий от RFC 8321
В этом документе определён метод чередующейся маркировки, устраняющий неоднозначности на основе экспериментов с использованием исходной спецификации [RFC8321], отличия от которой указаны ниже.
-
Добавлены рекомендации по методам, применяемым в случае наличия одного или двух битов, доступных для маркировки (раздел 7).
-
Изменена структура документа для улучшения читаемости.
-
Исключён текст о начальных экспериментах с методом и соображения, утратившие актуальность.
-
Расширено описание деталей метода, например, синхронизации, временных параметров, фрагментации пакетов, а также обработки маркированного и немаркированного трафика.
Важно отметить, что все изменения полностью совместимы с [RFC8321] и в документе не добавлено новых методов.
1.2. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
2. Обзор метода
Существуют разные подходы к измерению потерь пакетов в рабочем потоке трафика. Самым интуитивно понятным способом является нумерация пакетов, чтобы каждый маршрутизатор на пути потока мог сразу увидеть пропуск. Хотя этот подход очень прост в теории, реализовать его непросто и требуется внедрение порядкового номера в каждый пакет, а устройства должны быть способны извлекать эти номера в реальном масштабе времени. Такую задачу трудно реализовать на «живом» трафике — при использовании транспорта UDP порядковые номера не доступны, а если номер имеется в протоколе вышележащего уровня (например, в заголовке RTP), его извлечение в реальном масштабе времени может сильно нагружать устройство.
Другим решением является учёт пакетов на передающей и приёмной стороне и сравнение результатов. Эта операция значительно проще в реализации, но требует от устройств синхронизации учёта — для сравнения двух значений требуется, чтобы они были связаны с одним набором пакетов. Поскольку потоки непрерывны и не могут быть остановлены для чтения счётчика, сложно определить, когда нужно считывать значение счётчика. Возможным решением этой проблемы является виртуальное разделение потока на последовательные блоки путём периодической вставки разделителей, чтобы каждый счётчик относился к одному и тому же блоку пакетов. Таким разделителем может быть, например, специальный пакет, искусственно внедряемый в поток, однако этому методу присущи некоторые ограничения. Во-первых, он требует генерации дополнительных пакетов в потоке, а оборудование должно обрабатывать эти пакеты. Во-вторых, метод чувствителен к переупорядочению пакетов-разделителей и (в меньшей степени) к их потере.
Предлагаемый здесь метод использует второй подход, но без дополнительных пакетов для деления потока на блоки. Вместо этого пакеты маркируются так, что пакеты одного блока получают одну «окраску», а пакеты следующего блока — другую. Каждая смена цвета представляет сигнал самосинхронизации, гарантирующий согласованность измерений на разных устройствах в пути.
На рисунке 1 показана простая сеть и применение метода для учёта потерь в разных сегментах путём проведения измерений на разных интерфейсах в пути. Это может быть мониторинг узла, канала или сквозной мониторинг. Метод достаточно гибок для измерения потерь в любом сегменте сети и может служить для поиска сбойных элементов.
Поток трафика
========================================================>
+------+ +------+ +------+ +------+
---<> R1 <>-----<> R2 <>-----<> R3 <>-----<> R4 <>---
+------+ +------+ +------+ +------+
. . . . . .
. . . . . .
. <------> <-------> .
. Потери на узле Потери в канале .
. .
<--------------------------------------------------->
Сквозные потери пакетов
Рисунок 1. Доступные измерения.
3. Подробное описание метода
В этом разделе рассматриваются детали работы метода. Основное внимание уделено измерению потери пакетов, являющееся основным применением метода, а также применимость метода для измерения задержки и её вариаций.
3.1. Измерение потери пакетов
Идея заключается в виртуальном расщеплении потока трафика на последовательные блоки, каждый из которых представляет измеряемую сущность, однозначно распознаваемую всеми устройствами на пути через сеть. Учитывая число пакетов в каждом блоке, определённое разными сетевыми устройствами на пути, можно найти потери пакетов в любом блоке между парой точек сети.
Как отмечено выше, простым способом создания блоков является «окрашивание» трафика (двух цветов достаточно), чтобы пакеты последовательных блоков различались по цвету. Смена цвета указывает завершение блока и начало нового. Число пакетов в каждом блоке зависит от критериев создания блоков:
-
если цвет меняется после фиксированного числа пакетов, все блоки без потерь будут содержать одинаковое число пакетов;
-
если цвет меняется по фиксированному таймеру, число пакетов в блоке зависит от скорости передачи.
При реализации этой спецификации требуется создавать блоки по фиксированному таймеру. Смена окрашивания по фиксированному числу пакетов служит дополнительной возможностью, а детали этого выходят за рамки документа. Пример применения этого метода представлен в [EXPLICIT-FLOW-MEASUREMENTS].
На рисунке 2 показано, как выглядят блоки пакетов после окрашивания.
A - пакет цвета A
B - пакет цвета B
| | | | |
| | Поток трафика | |
------------------------------------------------------------------->
BBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA
------------------------------------------------------------------->
... | Блок 5 | Блок 4 | Блок 3 | Блок 2 | Блок 1
| | | | |
Рисунок 2. Окрашивание трафика.
На рисунке 3 показано применение метода для определения потери пакетов на канале между смежными узлами. Предположим, что мониторинг потери пакетов выполняется между маршрутизаторами R1 и R2. В соответствии с методом трафик окрашивается в цвета A и B. Смена цвета служит сигналом завершения блока, как показано в верхней части рисунка 3.
Цвет A ----------+ +-----------+ +----------
| | | |
Цвет B +-----------+ +-----------+
Блок n ... Блок 3 Блок 2 Блок 1
<---------> <---------> <---------> <---------> <--------->
Поток трафика
===========================================================>
Цвет ...AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA...
===========================================================>
Рисунок 3. Обнаружение потери пакета в канале.
Если трафик ещё не окрашен, R1 может сделать это. Маршрутизатору R1 нужны два счётчика на выходном интерфейсе — C(A)R1 учитывает пакеты цвета A, C(B)R1 — пакеты цвета B. Пока трафик имеет цвет A, инкрементируется лишь счётчик C(A)R1, а при трафике цвета B инкрементируется только C(B)R1. C(A)R1 и C(B)R1 могут служить эталонными значениями для определения потерь между R1 и любой другой точкой измерения на дальнейшем пути. Маршрутизатору R2 нужны два счётчика на входном интерфейсе — C(A)R2 и C(B)R2, учитывающие пакеты цвета A и B, соответственно. По завершении блока A можно сравнить значения C(A)R1 и C(A)R2 для определения числа потерянных пакетов блока. Аналогично по завершении блока B можно сравнить счётчики C(B)R1 и C(B)R2.
Точно также с использованием двух счётчиков на выходном интерфейсе R2 можно учесть пакеты, переданные интерфейсом R2, и использовать значения счётчиков для сравнения в следующей точке измерения.
Размер блоков можно выбрать достаточно большим для упрощения сбора и сравнения результатов на различных устройствах сети. Предпочтительно считывать значение счётчика не сразу при смене цвета, чтобы учесть возможное нарушение порядка доставки (некоторые пакеты могут прийти с запозданием и будут увеличивать значение счётчика). Безопасным сроком ожидания представляется L/2 (L — продолжительность каждого блока) перед считыванием счётчика предыдущего блока (раздел 5). Недостатком выбора большой протяжённости блока является более грубое измерение.
Возможны две стратегии реализации метода.
По потокам
Этот подход применяется в случаях, когда нужно отслеживать лишь чётко определённые потоки трафика, т. е. маркируется лишь часть потоков. Счётчики для измерения потерь можно создать для каждого потока или набора потоков в зависимости от требуемой детализации. С этим подходом связана проблема необходимости заранее знать путь измеряемого потока. Нужно учитывать смену пути и применение балансирования нагрузки.
По каналам
Измерения выполняются для всего трафика, проходящего по каналу, который может быть физическим или логическим. Счётчики задаются для трафика в целом или отдельных классов (если нужно отслеживать каждый класс независимо), но во втором случае требуется пара счётчиков для каждого класса.
Данная спецификация требует реализации измерений по потокам. Для этого нужна идентификация отслеживаемых потоков и определение пути нужного потока. Можно отслеживать один или группу потоков, но во втором случае измерение будет согласованным лишь прохождении всех потоков по одному пути. Кроме того, при группировке потоков невозможно точно определить, в каком потоке возникли потери. Для измерений на одном потоке нужно создать счётчики для каждого отслеживаемого потока. Когда контролируемые потоки указаны, требуется настроить мониторинг на соответствующих узлах. Настройка мониторинга означает задание правил для перехвата трафика и настройку счётчиков пакетов. Для выполнения сквозного мониторинга достаточно включить отслеживание на первом и последнем маршрутизаторе пути, в этом случае механизм просто не заметен промежуточным узлам и не зависит от выбора пути. При поэтапном (hop-by-hop) отслеживании на всем пути требуется включить отслеживание на каждом узле от источника до получателя. Если путь не известен заранее (имеется несколько путей между источником и получателем), требуется включить мониторинг на всех путях. Счётчики на интерфейсах фактического пути будут отслеживать потери пакетов, а прочие просто останутся неиспользуемыми (0).
3.2. Измерение односторонней задержки
Тот же принцип применяется при измерении задержки в одном направлении. Имеется две методики, описанных ниже.
Отметим, что для описанных ниже вариантов измерения односторонней задержки, всегда можно оценить круговую задержку, суммируя измеренные задержки в каждом направлении. Для измерения задержки можно применять метки времени в формате NTP3 [RFC5905] или IEEE 1588 Precision Time Protocol (PTP) [IEEE-1588].
3.2.1. Методика с одним маркером
Чередование цветов можно использовать как метку времени для расчёта задержки. Когда цвет меняется (новый блок), сетевое устройство может записать временную метку первого пакета в новом блоке, а затем это значение можно сравнить с меткой времени того же пакета на другом маршрутизаторе для расчёта задержки пакета. В примере на рисунке 2 маршрутизатор R1 сохраняет метку TS(A1)R1 при отправке первого пакета блока 1 (A), а метку TS(B2)R1 — при отправке первого пакета блока 2 (B) и т. д. R2 выполняет аналогичные операции на приёмной стороне, записывая TS(A1)R2, TS(B2)R2 и т. д. Поскольку метки относятся к конкретным пакетам (первому в каждом блоке), при отсутствии потерь и нарушения порядка пакетов можно быть уверенным, что сравнение временных меток выполняется для одного и того же пакета. Сравнивая метки TS(A1)R1 и TS(A1)R2 (аналогично, TS(B2)R1 и TS(B2)R2 и т. д.), можно определить задержку между R1 и R2. Для большего числа измерений можно сохранять дополнительные метки, относящиеся к другим пакетам того же блока, например, можно сохранять метки каждого N-го пакета. В пределе можно измерять задержку каждого пакета, сравнивая соответствующие метки времени (это может быть непрактично с точки зрения реализации).
Для когерентного сравнения временных меток от разных маршрутизаторов часы на узлах сети должны быть синхронизированы (раздел 5). Кроме того, измерения действительны лишь при отсутствии потерь и переупорядочения пакетов, поскольку в ином случае первый пакет на одном маршрутизаторе (R1) может оказаться не первым на другом (R2), например, при потере или нарушении порядка пакетов между маршрутизаторами R1 и R2. Поскольку нарушение порядка обычно не предсказуемо, нет возможности убедиться, что первый пакет на R1 будет первым и на R2, и это является частью присущих данному методу ошибок.
3.2.1.1. Средняя задержка
Метод, представленный для измерения задержки, подвержен влиянию нарушений порядка доставки пакетов. Для решения этой проблемы можно рассмотреть подход, основанный на концепции средней задержки, которая рассчитывается по среднему времени прибытия пакетов одного блока. Сетевое устройство локально сохраняет временные метки для каждого пакета в блоке, суммирует их значения и делит сумму на число полученных в блоке пакетов. Разность среднего времени прибытия от двух смежных устройств даёт среднюю задержку между этими узлами. Этот метод существенно сокращает число собираемых меток времени (1 метка на блок в каждом устройстве) и повышает устойчивость к переупорядочению пакетов и остаётся лишь небольшая ошибка в случае потери пакетов. Однако при расчёте средней задержки ошибка измерения может увеличиваться за накопления погрешностей при измерении большого числа пакетов. Кроме того, метод даёт лишь один результат для всего блока и не позволяет определить минимальную, максимальную и медианную задержку [RFC6703]. Детализацию измерений можно повысить, сократив продолжительность блока (например, до секунд вместо минут), но это предполагает сильно оптимизированную реализацию метода. По этой причине расчёт средней задержки может подходить не всегда.
3.2.2. Методика с двумя маркерами
Как отмечено выше, метод измерения односторонней задержки с одним маркером (Single-Marking) имеет некоторые ограничения, поскольку он чувствителен к нарушению порядка пакетов. Ограничения имеет и расчёт средней задержки, поскольку он не даёт сведений о распределении значений задержки в рамках блока. На практике может быть полезна не только средняя задержка, но и максимальное, минимальное и медианное значение, а в более широком смысле и статистическое распределение задержки. Поэтому для получения большей информации о задержке и исключения проблем связанных с нарушением порядка пакетов, можно использовать подход на основе двойной маркировки (Double-Marking).
Идея применения второго маркера, по сути, заключается в создании дополнительного потока и выбора в рамках окрашенного потока пакетов для измерения задержки и её вариаций. Первый маркер нужен для измерения потери пакетов и средней задержки, а второй создаёт новый набор помеченных пакетов, которые идентифицируются в сети, чтобы сетевые устройства могли сохранять метки времени из этих пакетов. Эти метки могут сравниваться на следующем маршрутизаторе с метками того же пакета для расчёта задержки каждого пакета. Число измерений легко увеличить, изменив частоту второй маркировки, однако она не должна быть слишком высокой, чтобы избежать проблем при нарушении порядка пакетов. Между пакетами со вторым маркером должен быть достаточный интервал, чтобы избежать проблем при нарушении порядка пакетов и обеспечить независимость числа измерительных пакетов от скорости передачи. Это может быть интервал не менее средней задержки в сети, рассчитанной первым методом. Следует выбрать подходящий интервал времени, чтобы обеспечить фиксированное число пакетов со вторым маркером, равномерно распределенных в каждом блоке. Потерю пакетов со вторым маркером легко распознать, поскольку число таких пакетов известно для каждого блока. По интервалу между этими пакетами можно также определить, какой из пакетов со вторым маркером был потерян, и выполнить измерения только для оставшихся пакетов. В этом случае реализация может просто отбросить измерения задержки в повреждённом блоке и перейти к следующему.
Эффективным и надёжным режимом является выбор одного пакета со вторым маркером для каждого блока. В этом случае нет временного промежутка между пакетами с двойной маркировкой что позволяет избежать их переупорядочивания. Кроме того, упрощается идентификация единственного пакета с двойным маркером в каждом блоке и пропускается измерение задержки в блоке при потере такого пакета.
Метод Double-Marking можно также применять для получения дополнительных сведений о статистике задержки, например, процентилей, дисперсии и медианных значений задержки. Для детального расчёта задержки выбирается подмножество пакетов с двумя маркерами и можно проанализировать их. Следует отметить, что имеются классические алгоритмы расчёта медианы и вариаций, но это выходит за рамки документа. Традиционного диапазона (максимум — минимум) следует избегать по нескольким причинам, включая стабильность максимального значения из-за внешних влияний. В параграфе 6.5 [RFC5481] отмечено, что процентиль 99,9 для задержки и её вариаций более полезен для оценок.
3.3. Измерение вариаций задержки
Подобно измерению односторонней задержки (с одним или двумя маркерами), метод подходит для измерения вариаций межпакетных интервалов (inter-arrival jitter) на основе определения RFC 3393 [RFC3393]. Смену цвета при использовании одного маркера можно применять в качестве отметки времени для измерения вариаций задержки. При двойной маркировке такие отметки задают пакеты со вторым маркером. В примере на рисунке 2 маршрутизатор R1 сохраняет метку TS(A)R1 при отправке первого пакета блока, а R2 сохраняет метку TS(B)R2 при получении первого пакета блока. Вариации можно легко получить по результатам измерения односторонней задержки, оценивая изменения задержки для последовательных выборок.
Концепция средней задержки тоже применима к измерению вариаций путём оценки среднего изменения интервала между последовательными пакетами блока от маршрутизаторов R1 и R2.
4. Функции чередующейся маркировки
4.1. Маркировка пакетов
Окрашивание является основой создания блоков пакетов и подразумевает выбор места и способа задания цвета.
При измерениях по потокам можно задать поток для отслеживания правилами отбора (например, полей заголовка) для сопоставления с подмножеством пакетов. Таким способом можно контролировать число вовлечённых узлов на пути следования пакетов и размеры потоков. В общем случае может быть один или несколько окрашивающих узлов, при этом использование одного узла упрощает управление и избавляет от конфликтов. При окрашивании на нескольких узлах требуется периодически менять окраску на них в соответствии с разделом 5, чтобы каждый измерительный узел на пути мог однозначно идентифицировать окрашенные пакеты. В [RFC9342] раскрашивание обобщено для потоков «многие со многими» (multipoint-to-multipoint). Кроме того, может быть выгодно окрашивать пакет ближе к источнику, поскольку это позволяет выполнять сквозные измерения, если это разрешено и на последнем маршрутизаторе в пути пакета.
При измерениях по каналам нужно окрашивать весь трафик, передаваемый в канал. Если трафик уже окрашен, он должен перекрашиваться, потому что окрашивание на канале должно быть согласованным. Это означает, что каждый интервал пересылки на пути должен окрасить или перекрасить трафик. Цвета на разных каналах могут отличаться.
Окрашивание трафика можно выполнить путём установки конкретного бита в заголовке пакета и периодической смены значения этого бита. Выбор поля для маркировки зависит от приложения и не задаётся здесь.
4.2. Подсчёт и временные метки для пакетов
Для измерений по потокам, в предположении окрашивания пакетов лишь на узлах-источниках, узлы между источником и получателем (включая его) учитывают полученные и пересланные окрашенные пакеты — эта операция может быть включена на всех или части маршрутизаторов пути, в зависимости от контролируемого сегмента сети (один канал, конкретная область городской сети, магистраль или весь путь). Поскольку окраска периодически меняется, нужны два счётчика (по одному для каждого цвета) для каждого отслеживаемого потока или группы потоков и каждого интерфейса, где включён мониторинг. Число сохраняемых меток времени зависит от применяемого метода измерения. В [RFC9342] подсчёт обобщён для потоков multipoint-to-multipoint.
В случае измерений по каналам поведение похоже, но окрашивание, учёт и операции с метками времени выполняются по каналам на их конечных точках.
Другим важным вопросом является выбор времени считывания счётчиков и отбор пакетов для двойной маркировки при измерении задержки. Это включает аспекты синхронизации, рассматриваемые более подробно в разделе 5.
4.3. Сбор и сопоставление данных
Узлы, включённые в мониторинг производительности, собирают значения счётчиков, но не могут использовать их напрямую для измерения потери пакетов, поскольку им известны лишь свои значения. Сбор данных позволяет передавать значения счётчиков и меток времени сразу после их получения. Сопоставление данных — это механизм сравнения значений счётчиков и меток времени для определения потери пакетов, задержки и её вариаций. Существует два основных способа сбора и сопоставления данных в зависимости от способа применения чередующейся маркировки.
-
Использование централизованного решения с системой управления сетью (Network Management System или NMS) для сопоставления данных. Это возможно в режиме выталкивания (Push) или опроса (Polling). В первом случае каждый маршрутизатор периодически отправляет свои сведения в NMS, во втором NMS периодически запрашивает данные у маршрутизаторов.
-
Выбор распределенного решения на основе протокола для обмена значениями счётчиков и временных меток между конечными точками. Это можно сделать путём введения нового протокола или расширения имеющихся, таких как TWAMP4 [RFC5357] или OWAMP5 [RFC4656]), для передачи счётчиков и меток между узлами.
Ниже объясняется пример механизма сопоставления данных, который можно применять независимо от решения.
При сборе данных (например, значений счётчиков для измерения потерь или меток времени для измерения задержки) на узлах восходящего или нисходящего направления с периодической отправкой (выталкивание или опрос) другим узлам или NMS следует применять тот или иной механизм сопоставления, чтобы помочь узлам или NMS определить, связаны ли значения с одним и тем же помеченным пакетом.
Описанный в документе метод чередующейся маркировки делит пакеты измеряемого потока на измерительные блоки. Для сопоставления реализация может использовать номера таких блоков (Block Number или BN). Значение BN должно присваиваться каждому блоку и связываться с каждым значением счётчика пакетов или временной метки, передаваемым другим уздам и NMS или запрашиваемым ими. Когда узлы или NMS видят, например, один и тот же BN, связанный с двумя счётчиками пакетов от восходящего и нисходящего узла, они относят эти счётчики к одному блоку. Этот механизм предполагает синхронизацию часов на измерительных узлах, для чего узлы должны иметь соответствующие средства (например, NTP [RFC5905] или IEEE 1588 PTP [IEEE-1588]).
5. Синхронизация и хронометраж
Смена цвета служит триггером для всех сетевых устройств, являющихся точками измерения, а единственное требование заключается в том, что они устройства распознавать блоки для получения соответствующих значений счётчиков и меток времени.
В общем случае часы в сетевых устройствах не точны и время на маршрутизаторах R1 и R2 будет различаться. Для реализации этого метода часы требуется синхронизировать от одного источника с адекватной точностью, чтобы все устройства согласованно сопоставляли биты маркировки с корректным блоком. На практике кроме несоответствия часов часто меняется порядок доставки пакетов в сети в результате применения нескольких равноценных путей (equal-cost multipath или ECMP). Задержка между точками измерения является основной причиной нарушения порядка пакетов, поскольку может быть своей у каждого пакета. Если блок достаточно велик, переупорядочение пакетов значимо лишь на границе смежных блоков и такие пакеты легко связать с нужным блоком.
Таким образом, нужно учитывать два фактора — несогласованность часов на устройствах сети и интервал ожидания, позволяющий избежать привязки пакета не к тому блоку. Рисунок 4 иллюстрирует это (L — продолжительность блока).
...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB...
|<======================================>|
| L |
...=========>|<==================><==================>|<==========...
| L/2 L/2 |
|<===>| |<===>|
d | | d
|<==========================>|
Доступный интервал учета
Рисунок 4. Аспекты синхронизации.
Предполагается, что все сетевые устройства синхронизированы с общим эталоном с точностью ±A/2. Таким образом, разница между любой парой часов ограничена значением A. Задержку между сетевыми устройствами можно представить как нормальное распределение и 99,7% выборок будут находиться в пределах 3 стандартных отклонений от среднего значения. «Защитная полоса» определяется выражением
d = A + D_avg + 3*D_stddev,
где A — точность часов, D_avg — среднее значение задержки между сетевыми устройствами, D_stddev — стандартное отклонение задержки. Доступный интервал учёта составляет L — 2d, что должно быть больше 0.
Условие, которое должно быть выполнено и является требованием к точности синхронизации, имеет вид:
d < L/2.
Это фундаментальное правило для выбора времени считывания счётчиков и отбора пакетов для двойной маркировки, которые должны выполняться в пределах доступного интервала подсчёта, нне подверженного влиянию ошибок.
Если продолжительность каждого блока (L) не слишком мала, требование синхронизации можно выполнить даже при сравнительно неточном методе.
6. Фрагментация пакетов
При наличии фрагментации чередующуюся маркировку следует применять в соответствии с приведёнными ниже рекомендациями.
Узлы маркировки должны помечать все фрагменты, где имеются биты флагов (зависит от инкапсуляции), как отдельные пакеты.
Узлам, фрагментирующим пакеты внутри домена измерений, следует, при наличии возможности, включать биты маркировки из исходного пакета лишь в один результирующий фрагмент, поскольку иначе могут возникать ошибки в измерениях.
Точкам измерения следует просто игнорировать фрагменты без маркеров и учитывать маркированные фрагменты как полные пакеты. При наличии ресурсов точки измерения могут отмечать как маркированные, так и немаркированные пакеты, инкрементируя соответствующий счётчик лишь в случаях, когда (a) другие фрагменты тоже маркированы или (b) наблюдаются все остальные фрагменты и они не имеют маркеров.
Предложенный подход позволяет узлу маркировки помечать все фрагменты, за исключением случая фрагментации внутри домена, где предлагается маркировать лишь первый фрагмент.
7. Рекомендации по внедрению
Описанные выше методы можно применять в различных задачах измерения производительности. Единственным требованием является выбор и маркировка интересующего потока. Пакеты группируются в блоки отправителем и блоки маркируются с чередованием цвета, чтобы получатель мог легко отличить один блок от другого. В [RFC8321] описаны примеры экспериментов, а в [IEEE-NETWORK-PNPM] даны некоторые сведения об опыте внедрения.
В разных системах для маркировки может быть доступен 1 или 2 бита флагов.
Один флаг
Измерение потери пакетов должно выполняться в соответствии с параграфом 3.1, а измерение задержки должно использовать метод с одним маркером, как описано в параграфе 3.2.1. Можно также измерять среднюю задержку (параграф 3.2.1.1), но это повысит расчётную нагрузку.
Два флага
Измерение потери пакетов должно выполняться в соответствии с параграфом 3.1, а измерение задержки должно использовать метод с двумя маркерами, как описано в параграфе 3.2.2. В этом случае можно также использовать одинарную маркировку в комбинации с двойной и эти подходы будут давать слегка различающиеся результаты, которые можно объединить для получения более надёжных данных.
Ниже приведены некоторые рекомендации по выбору решения об использовании одного или двух флагов.
-
Метод чередующейся маркировки использует конкретные флаги в заголовке пакета, поэтому важным фактором является число доступных для реализации битов. При доступности единственного флага имеется лишь 1 вариант, а наличие двух флагов позволяет расширить возможности.
-
Длительность периода маркировки (протяжённость блока) влияет на частоту измерений и этот параметр можно выбирать на основе требований к частоте выборки. Однако выбор ограничен, как указано в разделе 5.
-
Методы чередующейся маркировки позволяют рассчитать потери пакетов, задержки и их вариации, но набор получаемых сведений зависит от применяемого метода (один или два маркера). Например, для получения более подробной статистики в рамках блока желательно использовать два флага. По этой причине следует также учитывать тип данных, требуемых в конкретном варианте применения.
-
Методы чередующейся маркировки создают разную вычислительную нагрузку, поэтому при выборе метода нужно учитывать расчётные возможности точек измерения. Например, для расчёта средней задержки может потребоваться больше вычислений и это будет не лучшим вариантом, если нужно минимизировать расчётную нагрузку.
Эксперименты с методами чередующейся маркировки подтвердили преимущества, описанные в [RFC8321].
При внедрении метода чередующейся маркировки следует учитывать способы распознавания трафика с маркерами и без них. Поскольку для маркировки обычно применяются выделенные, резервные поля, включённые в расширение протокола, точки измерения могут определить активно ли измерение, проверяя наличие в пакетах соответствующего расширения.
Следует упомянуть некоторые смежные работы, в частности [IEEE-NETWORK-PNPM], где описывается чередующаяся маркировка в сочетании с новыми механизмами на основе хэширования.
7.1. Применение в контролируемом домене
Метод чередующейся маркировки является примером решения, доступного лишь в контролируемом домене [RFC8799].
Контролируемым доменом считается управляемая сеть, которая выбирает, отслеживает и контролирует доступ путём применения правил на границе домена для отбрасывания нежелательных внешних пакетов на входе в домен и проверки выходящих из домена пакетов. Это не обязательно предполагает единое администрирование или одну организацию. Контролируемый домен может включать один или несколько административных доменов с заданным управлением. В контролируемом домене должна быть возможность контроля границ и принятия специальных мер для аутентификации, шифрования и защиты целостности, если трафик проходит через Internet.
Из соображений безопасности чередующаяся маркировка должна применяться лишь внутри контролируемых доменов.
8. Соответствие рекомендациям RFC 6390
В [RFC6390] определена модель и процессы разработки показателей производительности для протоколов, работающих выше и ниже уровня IP (таких, как работающие на основе IP приложения, использующие надёжный или дейтаграммный транспорт).
Этот документ не имеет цели предложить новый показатель производительности, а скорее предлагает новую методику измерений для нескольких PM, которые уже стандартизованы. Тем не менее, к документу следует применить рекомендации [RFC6390], чтобы обеспечить более полное и согласованное описание предложенного метода. Описанный в документе механизм использует шаблон Performance Metric Definition, заданный в параграфе 5.4 [RFC6390], и зависимости из параграфа 5.5 в том же документе.
Название и описание показателя
Как уже отмечено, этот документ не задаёт новых PM, описывает новый метод измерения потерь пакетов [RFC7680]. Та же концепция с небольшими отличиями может применяться для измерения задержки [RFC7679] и её вариаций [RFC3393]. Документ в основном описывает применимость метода к измерению потерь пакетов.
Метод измерения или расчёта
В соответствии с описанным выше методом число потерянных пакетов рассчитывается путём вычитания значения счётчика на узле-источнике из значения счётчика на целевом узле6 (оба счётчика должны относиться к одному цвету). Расчёт выполняется для установившихся (стабильных) значений счётчиков. Установившееся состояние является неотъемлемой характеристикой счётчиков этого метода, поскольку смена цвета делает связанный с этим цветом счётчик неактивным (установившимся) в течение интервала маркировки другим цветом.
Единицы измерения
Метод рассчитывает и сообщает точное число пакетов, переданных источником и не полученных адресатом.
Точки измерения и возможная область измерений
Измерения могут выполняться на смежных узлах, по каналу или на пути с множеством пересылок (multi-hop) при условии следования по этому пути всего трафика. Для пути с несколькими пересылками измерения могут выполняться для конечных точек или по этапам пересылки.
Хронометраж измерений
Методу присущи ограничения по частоте измерений. Это подробно описано в разделе 5, где указано, что период маркировки и «защитная полоса» строго связаны между собой во избежание проблем при нарушении порядка пакетов. Это связано с тем, что для измерения счётчик должен быть в установившемся состоянии, а это происходит в интервале маркировки другим цветом.
Реализация
Метод использует 1 или 2 бита для маркировки пакетов. Это позволяет использовать на маршрутизаторах правила маркировки пакетов и задавать соответствующую каждому цвету конфигурацию. Путь измеряемого трафика следует знать заранее для настройки счётчиков на этом пути и возможности сравнения корректных значений.
Проверка
Методика была экспериментально развёрнута и протестирована в лаборатории и рабочих сетях для измерения потерь и задержки пакетов при разных картинах трафика, создаваемого генераторами, а также точными инструментами тестирования и эмуляторами сетей.
Использование и приложения
Метод можно применять для высокоточного измерения потерь в реальном трафике, комбинируя сквозные измерения с измерениями по каналам. Метод полезен для нахождения конкретного канала, где происходят потери.
Модель отчётов
Значения счётчиков передаются в централизованную систему управления сетью, где выполняются расчёты. Выборки должны включать ссылку на интервал времени, когда они выполнялись, чтобы система управления могла провести корректное сопоставление данных. Выборка передаётся в то время, когда соответствующий счётчик находится в установившемся состоянии (в течение интервала времени), в остальное время выборка сохраняется локально.
Зависимости
Значения счётчиков сопоставляются с интервалом времени, к которому они относятся.
Организация результатов
Метод измерения даёт одиночные результаты (singleton) в соответствии с определением [RFC2330].
Параметры
Основными параметрами метода являются сведения об измеряемом потоке или канале, интервал чередования цвета и тип метода, выбранный для измерения потерь и задержки.
9. Взаимодействие с IANA
Этот документ не требует действий IANA.
10. Вопросы безопасности
Этот документ задаёт метод для выполнения измерений, который не влияет напрямую на безопасность Internet или приложений сети Internet. Однако при реализации метода нужно помнить о безопасности и приватности.
Проблемы безопасности могут быть связаны с помехами измерениям и нарушением работы сети при измерениях.
-
Вред, вызванный измерениями. Описанные здесь измерения являются пассивными и в сеть не внедряется новых пакетов, способных повредить трафику данных. Тем не менее, метод подразумевает изменение заголовков или инкапсуляции пакетов «на лету». Эти действия должны выполняться так, чтобы не оказывалось влияния на качество обслуживания выбранных для измерения пакетов, а также на стабильность и производительность маршрутизаторов, выполняющих измерения. Одной из основных угроз безопасности в протоколах OAM7 является сетевая разведка — злоумышленник может собрать информацию о работе сети, пассивно прослушивая сообщения OAM. Преимущество описанного здесь метода заключается в том, что сетевые устройства обмениваются лишь битами маркировки, поэтому пассивный перехват пакетов плоскости данных не позволит злоумышленнику получить сведения о производительности сети.
-
Вред самим измерениям может быть нанесён маршрутизаторами, меняющими маркировку пакетов, или злоумышленниками, внедряющими искусственный трафик. Можно применять методы аутентификации, такие как цифровые подписи, для защиты от атак с внедрением трафика. Поскольку на измерения могут влиять маршрутизаторы (или иные устройства) на пути пакетов IP, намеренно меняя биты маркировки, как отмечено выше, описанный в документе механизм следует применять лишь в рамках контролируемого домена, где применяется единое (локальное) администрирование для маршрутизаторов (и иных устройств), что позволяет предотвратить упомянутые атаки.
Злоумышленник вне контролируемого домена может злонамеренного передавать пакеты с маркировкой. Это не вызовет проблем, если в контролируемом домене не поддерживается маркировка с чередованием. Если же такая маркировка применяется в домене, потребуется предотвратить искажение результатов измерений путём проверки маркеров в приходящих извне пакетах с соответствующей фильтрацией или сбросом маркеров.
Одним из условий применения метода является то, что он должен использоваться в конкретных контролируемых доменах, что позволяет ограничить векторы возможных атак. Ограниченный административный домен позволяет администратору выбирать, отслеживать и контролировать доступ в сеть, делая домен доверенным. В таком контексте предполагается применение на границе домена правил для фильтрации внешних пакетов с маркировкой на входе в домен и внутренних маркированных пакетов — на выходе из домена. Таким образом, атаки с перехватом пакетов становятся маловероятными, поскольку пакеты с маркировкой применяются и обрабатываются только в рамках контролируемого домена. Тем не менее, возможность утечек маркированных пакетов сохраняется, например, в случаях отказов или неисправностей. В таких случаях предполагается, что маркировка в пакетах будет игнорироваться внешними узлами, поскольку они не настроены на обработку маркеров.
Теоретически можно модулировать маркировку для создания скрытых каналов, которые может использовать находящийся на пути злоумышленник. Это может влиять как на плоскость данных, так и на плоскость управления, однако применение метода в рамках контролируемого домена позволяет смягчить последствия таких действий.
Следует подчеркнуть, что атакующий не сможет получить данных о производительности сети, имея лишь одну точку мониторинга, поскольку для работы метода нужны две синхронизированные точки на разных участках пути. Злоумышленник для получения сведений должен применять те же методы измерения и агрегирования, какие используют сервис-провайдеры.
Атаки на сбор данных и передачу статистики между точками мониторинга и NMS могут помешать корректной работе системы, поэтому каналы, служащие для передачи статистики, должны быть защищены.
Проблемы приватности при выполнении измерений незначительны, поскольку метод использует лишь сведения из заголовков (инкапсуляции) и не затрагивает данные пользователей. Хотя сведения в заголовках и инкапсуляции являются метаданными, которыми можно воспользоваться для нарушения приватности пользователей, маловероятно, что описанный в документе метод повысит имеющиеся риски. Теоретически можно модулировать маркировку для создания скрытого канала, но это будет слишком низкоскоростной канал, чтобы повлиять на измерительную систему, служащую для мониторинга маркировки.
Другой потенциальной угрозой в контексте этого документа являются атаки с задержкой. Измерения задержки выполняются с использованием конкретных пакетов в каждом блоке, выделенных цветом. Поэтому злоумышленник на пути может искусственно задержать соответствующие пакеты, внося систематическую ошибку в измерение задержки. Как отмечено выше, описанный метод основан на базовом протоколе синхронизации часов. Таким образом, атакуя этот протокол, злоумышленник потенциально может нарушить целостность измерений. Подробное описание угроз для протоколов синхронизации и способов их смягчения дано в RFC 7384 [RFC7384].
11. Литература
11.1. Нормативные документы
[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>.
[RFC3393] Demichelis, C. and P. Chimento, «IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)», RFC 3393, DOI 10.17487/RFC3393, November 2002, <https://www.rfc-editor.org/info/rfc3393>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., «A One-Way Delay Metric for IP Performance Metrics (IPPM)», STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., «A One-Way Loss Metric for IP Performance Metrics (IPPM)», STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>.
[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>.
11.2. Дополнительная литература
[EXPLICIT-FLOW-MEASUREMENTS] Cociglio, M., Ferrieux, A., Fioccola, G., Lubashev, I., Bulgarella, F., Nilo, M., Hamchaoui, I., and R. Sisto, «Explicit Flow Measurements Techniques», Work in Progress8, Internet-Draft, draft-ietf-ippm-explicit-flow-measurements-02, 13 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-explicit-flow-measurements-02>.
[IEEE-1588] IEEE, «IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems», IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.
[IEEE-NETWORK-PNPM] Mizrahi, T., Navon, G., Fioccola, G., Cociglio, M., Chen, M., and G. Mirsky, «AM-PM: Efficient Network Telemetry using Alternate Marking», IEEE Network Vol. 33, Issue 4, DOI 10.1109/MNET.2019.1800152, July 2019, <https://doi.org/10.1109/MNET.2019.1800152>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, «A Two-Way Active Measurement Protocol (TWAMP)», RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5481] Morton, A. and B. Claise, «Packet Delay Variation Applicability Statement», RFC 5481, DOI 10.17487/RFC5481, March 2009, <https://www.rfc-editor.org/info/rfc5481>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.
[RFC6390] Clark, A. and B. Claise, «Guidelines for Considering New Performance Metric Development», BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <https://www.rfc-editor.org/info/rfc6390>.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, «Reporting IP Network Performance Metrics: Different Points of View», RFC 6703, DOI 10.17487/RFC6703, August 2012, <https://www.rfc-editor.org/info/rfc6703>.
[RFC7384] Mizrahi, T., «Security Requirements of Time Protocols in Packet Switched Networks», RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[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>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, «Alternate-Marking Method for Passive and Hybrid Performance Monitoring», RFC 8321, DOI 10.17487/RFC8321, January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8799] Carpenter, B. and B. Liu, «Limited Domains and Internet Protocols», RFC 8799, DOI 10.17487/RFC8799, July 2020, <https://www.rfc-editor.org/info/rfc8799>.
[RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and T. Zhou, «Clustered Alternate-Marking Method», RFC 9342, DOI 10.17487/RFC9342, December 2022, <https://www.rfc-editor.org/info/rfc9342>.
Благодарности
Спасибо Alberto Tempia Bonda, Luca Castaldelli и Lianshu Zheng за вклад в эксперименты по проверке метода.
Авторы также благодарны Martin Duke и Tommy Pauly за помощь, а также подробные и точные рецензии.
Участники работы
Адреса авторов
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.
3Network Time Protocol — протокол сетевого времени.
4Two-Way Active Measurement Protocol — протокол активных двухсторонних измерений. Прим. перев.
5One-Way Active Measurement Protocol — протокол активных односторонних измерений. Прим. перев.
6Следует отметить, что такой расчёт даёт отрицательное значение потерь. Прим. перев.
7 Operations, Administration, and Maintenance — эксплуатация, администрирование и техническое обслуживание.
8Опубликовано в RFC 9506. Прим. перев.