RFC8911 Registry for Performance Metrics

image_print
Internet Engineering Task Force (IETF)                        M. Bagnulo
Request for Comments: 8911                                          UC3M
Category: Standards Track                                      B. Claise
ISSN: 2070-1721                                                   Huawei
                                                              P. Eardley
                                                                      BT
                                                               A. Morton
                                                               AT&T Labs
                                                               A. Akhter
                                                              Consultant
                                                           November 2021

Registry for Performance Metrics

Реестр показателей производительности

PDF

Аннотация

Этот документ задаёт формат реестра IANA Registry для метрик производительности, а также даёт рекомендации для запрашивающих и рецензирующих регистрацию показателей производительности.

Статус документа

Документ содержит проект стандарта Internet (Standards Track).

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8911.

Авторские права

Copyright (c) 2021. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML.

1. Введение

IETF задаёт и применяет показатели производительности (Performance Metrics) протоколов и приложений, доставляемых ими. Эти показатель являются важной частью сетевых операций, использующих протоколы IETF и в [RFC6390] даны рекомендации по их разработке.

Определением и использованием показателей производительности занимались в IETF несколько рабочих групп (working group или WG), наиболее важные из которых указаны ниже.

  • Группа показателей производительности IP (IP Performance Metrics или IPPM) занимается в основном определениями показателей производительности в рамках IETF.

  • Группа методологии тестирования (Benchmarking Methodology или BMWG) определила много показателей производительности для использования при лабораторном тестировании межсетевых технологий.

  • Группа Metric Blocks for use with RTCP’s Extended Report Framework (XRBLOCK), работа которой уже завершена, задала множество показателей, относящихся к расширенным отчётам протокола управления RTP (RTP Control Protocol Extended Reports или RTCP XR) [RFC3611], задающим модель, позволяющую передавать новую информацию в RTCP, дополняя исходные блоки отчётов, заданные в «RTP: A Transport Protocol for Real-Time Applications» [RFC3550].

  • Группа IP Flow Information eXport (IPFIX), завершившая свою работу, задала процесс IANA (Internet Assigned Numbers Authority) для выделения новых информационных элементов. Некоторые элементы, связанные с показателями производительности, предлагаются на регулярной основе.

  • Группа Performance Metrics for Other Layers (PMOL), завершившая работу, задала некоторые показатели производительности для качества голосовой связи по протоколу SIP (Session Initiation Protocol) [RFC6035].

Предполагается, что будут заданы новые параметры производительности не только для IP, но и для других протоколов и приложений.

Несмотря на важность показателей производительности в отрасли имеются 2 связанных с этим проблемы.

  1. Обеспечение того, чтобы при запросе одной стороны измерения другой стороной определённых показателей производительности (и информирования о нем) обе стороны имели общее представление о соответствующих показателях.

  2. Определение заданных показателей производительности для предотвращения разработки новых показателей, которые очень похожи, но недостаточно совместимы.

Эти проблемы могут быть решены созданием реестра для показателей производительности в IANA. Для этого данный документ определяет новый реестр IANA для параметров производительности (Performance Metrics).

На основании этого документа агентство IANA создало и поддерживает Performance Metrics Registry в соответствии с процедурами и форматом, заданными ниже. Реестр Performance Metrics предназначен для использования IETF и другими. Хотя приведённые здесь спецификации форматирования реестра предназначены в основном для IANA, их могут применять и другие организации, желающие создать свой реестр показателей производительности. Авторы не гарантируют применимость формата реестра для всех наборов показателей производительности, но рекомендуют использовать этот формат. Далее в документе поддерживаемый IANA реестр показателей производительности называется просто Performance Metrics Registry, если явно не указано иное.

2. Терминология

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Performance Metric – показатель (метрика) производительности

Количественная мера производительности, предназначенная для заданного IETF протокола или приложения, доставляемого по протоколу IETF. Примерами показателей производительности служат время отклика FTP для полной загрузки файла, время отклика DNS для распознавания адресов IP, время регистрации в базе данных (logging) и т. п. Это определение согласуется с определением показателя (метрики) в [RFC2330] и шире определения показателя производительности из [RFC6390].

Registered Performance Metric – зарегистрированный показатель производительности

Показатель производительности, включенный как запись в Performance Metrics Registry, администрируемый IANA. Такие показатели соответствуют всем критериям, заданным этим документом для включения в реестр.

Performance Metrics Registry – реестр показателей производительности

Реестр IANA, содержащий зарегистрированные показатели производительности.

Proprietary Registry – фирменный (приватный) реестр

Набор показателей, включённых в частный реестр, но не в Performance Metrics Registry.

Performance Metrics Experts – эксперты по показателям производительности

Группа экспертов, выбранных IESG [RFC8126], для проверки показателей производительности перед обновлением Performance Metrics Registry. Эти эксперты тесно сотрудничают с IANA.

Parameter – параметр

Элемент ввода, заданный как переменная в определении Performance Metric. Параметр – это число или иное значение из набора, определяющего показатель или условия работы. Все параметры должны быть известны для использования метрики и интерпретации результатов. Имеется два типа параметров – фиксированные и рабочие (Runtime). Для фиксированных параметров значение переменной задаётся в записи Performance Metrics Registry и разные значения параметра ведут к разным Registered Performance Metric. Для рабочих параметров значение переменной определяет метод измерения (Metric Measurement Method) и данный показатель поддерживает несколько значений параметра. Хотя рабочие параметры не меняют фундаментальной природы определения показателя производительности, некоторые из них оказывают существенное влияние на используемое свойство сети и интерпретацию результатов.
Примечание. Рассмотрим случай потери пакета в двух вариантах активного измерения. В первом случае потеря пакета является фоновой, когда установка рабочего значения параметра задаёт очень разреженный поток Пуассона и характеризует лишь время потери пакетов. Фактические пользовательские потоки вероятно будут выше в результате отбрасывания хвостов (tail drop) или ошибок в радиоканале. Во втором случае доля теряемых пакетов определяется коэффициентом дополнительной вероятности доставки, когда рабочее значение параметра задаёт очень плотный, прерывистый поток и характеризует потери, испытываемые потоками, близкими к пользовательским. Оба показателя являются «метрикой потерь», но различие в интерпретации результатов сильно зависит от рабочих параметров (по меньшей мере). В экстремальном случае коэффициент потерь фактически используется для вывода дополнительной вероятности – коэффициента доставки.

Active Measurement Methods – активные методы измерения

Методы измерения, применяемые к трафику, который служит лишь для измерительных целей, генерируется только для этого и имеет заранее известные характеристики. Полное определение активных методов дано в параграфе 3.4 [RFC7799]. Примерами активных методов являются методы измерения односторонней задержки из [RFC7679] и длительности кругового обхода из [RFC2681].

Passive Measurement Methods – пассивные методы измерения

Методы измерения, применяемые к трафику, создаваемому (1) конечным пользователем или (2) элементами сети и существующему независимо от проведения измерений. Полное определение пассивных методов дано в параграфе 3.6 [RFC7799]. Одной из характеристик пассивных методов является возможность наблюдения конфиденциальной информации и её сохранения в измерительной системе.

Hybrid Measurement Methods – гибридные методы измерения

Методы измерения, использующие комбинации активных и пассивных методов для доступа к активным и пассивным показателям, а также к новым показателям, выведенным a priori на основе знаний и наблюдений за интересующими потоками. Полное определение гибридных методов дано в параграфе 3.8 [RFC7799].

3. Область действия

Этот документ предназначен для двух разных аудиторий.

  1. Для тех, кто готовит потенциальные показатели производительности, документ предоставляет критерии, которым предложению следует соответствовать (раздел 5). Документ также содержит инструкции по написанию текстов для каждого столбца кандидата в показатель производительности и ссылок, требуемых для новой записи Performance Metrics Registry (вплоть до включения публикации неизменяемых документов, таких как RFC). См. раздел 7.

  2. Для назначенных экспертов Performance Metrics и персонала IANA, администрирующего новый реестр IANA Performance Metrics Registry, документ задаёт набор критериев приемлемости при оценке кандидатов в Registered Performance Metric и требований к созданию записей в Performance Metric Registry.

Другие организации, стандартизующие показатели производительности, призываются использовать описанный здесь процесс для того, чтобы предлагать кандидатов в Registered Performance Metric. Кроме того, документ может быть полезен организациям, определяющим свои реестры показателей производительности, которые могут воспользоваться определёнными здесь свойствами Performance Metrics Registry.

Реестр Performance Metrics применим к показателям производительности, выведенных из активных и пассивных измерений, а также другим формам Performance Metric. Реестр предназначен для включения показателей производительности через IETF, особенно для технологий, заданных рабочими группами IPPM, XRBLOCK, IPFIX, BMWG. Документ анализирует прежнюю попытку создать Performance Metrics Registry и причины её неудачи [RFC6248].

Документ [RFC8912] задаёт исходное содержимое нового реестра.

4. Мотивы создания Performance Metrics Registry

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

4.1. Взаимодействие

Как и для других реестров IETF, основной задачей является поддержка регистрации идентификаторов для использования в протоколах. В конкретном случае Performance Metrics Registry имеется два типа протоколов, которые будут использовать показатели производительности из реестра в своей работе (через индексы).

Control Protocol – протокол управления

Этот тип протоколов применяется для того, чтобы один объект мог запросить выполнение измерений другим объектом с использованием конкретной метрики, определённой в Performance Metrics Registry. Одним из примеров является модель крупномасштабных измерений производительности широкополосных систем (Large-scale Measurement of Broadband Performance или LMAP) [RFC7594]. В терминологии LMAP реестр Performance Metrics применяется в LMAP Control Protocol, чтобы позволить контроллеру запланировать измерительную задачу (Measurement Task) для одного или нескольких агентов измерения. Для такого варианта использования записи в Performance Metrics Registry должны быть достаточно определёнными, чтобы реализация Measurement Agent могла запустить Measurement Task при получении сообщения Control Protocol. Это требование сильно ограничивает типы записей, подходящих для Performance Metrics Registry.

Report Protocol – протокол отчётов

Этот тип протокола служит для того, чтобы объект мог передать результаты измерений другому объекту. Указывая конкретную зарегистрированную метрику производительности, можно верно охарактеризовать передаваемые результаты измерений. В терминологии LMAP реестр Performance Metrics применяется в LMAP Report Protocol для того, чтобы Measurement Agent мог передать результаты измерений коллектору (Collector).

Следует отметить, что модель LMAP явно позволяет применять не только поддерживаемый IANA реестр Performance Metrics, но и другие реестры показателей производительности, т. е. (1) реестры, заданные другими организациями или (2) частные реестры. Однако тем, кто создаёт реестры для применения в контексте модели LMAP, рекомендуется использовать заданный в этом документе формат реестра, поскольку это упрощает разработчикам измерительных агентов LMAP использование сведений из таких реестров.

4.2. Единая точка ссылок на метрики производительности

Performance Metrics Registry служит единой точкой ссылок на показатели производительности, заданные различными группами в IETF. Как отмечено выше, определением Performance Metrics в IETF занимается несколько рабочих групп и было бы сложно отслеживать все группы. Группы могут создавать несколько определений похожих показателей производительности, пытающихся измерять одно и то же слегка различающимися (и несовместимыми) способами. Наличие реестра позволит сообществу IETF и другим лицам иметь единый список Performance Metrics, определённых IETF (и другими в подходящих случаях). Единый список также важен для обмена сведениями о показателях производительности, где разные объекты, запрашивают и выполняют измерения, а также сообщают о результатах и могут получить преимущества из общего понимания соответствующих показателей производительности.

4.3. Дополнительные преимущества

Наличие реестра даёт несколько дополнительных преимуществ. Во-первых, Performance Metrics Registry может служить перечнем полезных и используемых показателей производительности, которые обычно поддерживаются разными реализациями измерительных агентов. Во-вторых, результаты измерений с использованием Performance Metrics будут сравнимыми даже при измерении с помощью разных реализаций и в разных сетях, поскольку метрика производительности определена должным образом. В BCP 176 [RFC6576] проверялась эквивалентность результатов, созданных независимыми реализациями в контексте оценки полноты и чёткости спецификаций показателей. Документ [RFC6576] относится к категории BCP [RFC2026] и определяет развитие документов Standards Track для (Active) IPPM Metrics. Такого же процесса будет, вероятно, достаточно для проверки спецификаций Registered Performance Metrics по части сравнимости (или эквивалентности) результатов тестов. Если зарегистрированный показатель производительности прошёл такую проверку, это следует указать в категории Comments and Remarks (см. параграф 7.6) со ссылкой на результаты теста.

5. Критерии регистрации метрик производительности

Помещать все комбинации параметров каждого показателя производительности в Performance Metrics Registry нежелательно и нецелесообразно. Ниже указаны требования, которые показателям следует соблюдать.

  1. Понятность для человека.

  2. Реализуемость на программном или аппаратном уровне.

  3. Возможность развёртывания сетевыми операторами.

  4. Точность в части получения эквивалентных результатов, а также совместимость и развёртываемость продукции разных производителей.

  5. Практическая полезность, что означает высокий интерес отрасли и/или уже наличие реализаций.

  6. Достаточная чёткость определений, чтобы разные значения рабочих параметров не меняли фундаментальной природы измерений или практичность их реализации.

По сути, должно быть доказано, что (1) кандидат на регистрацию метрики представляет отраслевой интерес или уже внедрён и (2) имеется согласие по части того, что метрика-кандидат служит предусмотренной цели.

6. Performance Metrics Registry – предыдущая попытка

Попытка определить реестр показателей производительности уже была предпринята в [RFC4148]. Однако документ был отменен [RFC6248], поскольку «было обнаружено, что он недостаточно детализирован для однозначной идентификации показателей IPPM [много иных замечаний] возможны вариации в точных характеристиках показателей», что привело к тому, что IPPM Metrics Registry из [RFC4148] «имеет очень мало пользователей или их нет совсем».

Три интересных дополнительных цитаты из [RFC6248] могут помочь в понимании связанных с реестром проблем.

  1. Не представляется возможным или полезным регистрировать каждую комбинацию Type P, параметров метрики и параметров потока (Stream) с использованием текущей структуры IPPM Metrics Registry.

  2. Текущая структура реестра оказалась недостаточно детальной для однозначной идентификации показателей IPPM.

  3. Несмотря на усилия по поиску имеющихся и даже потенциальных пользователей, никто не ответил на призыв проявить интерес к реестру RFC 4148 во второй половине 2010 г.

Текущий подход извлёк уроки из этого и чётко определяет каждый регистрируемый показатель производительности (Registered Performance Metric) с небольшим числом переменных (Runtime) параметров, которые нужно указать разработчику измерения, если таковые имеются. Идея состоит в том, что записи Performance Metrics Registry происходят от разных методов измерения, которым нужны входные (Runtime) параметры для установки таких значений, как адреса отправителя и получателя (это не меняет фундаментальной природы измерений). Обратной стороной такого подхода является возможность появления большого числа записей в Performance Metrics Registry. Имеется согласие, что в этом контексте «меньше значит больше» и лучше иметь сокращённый набор полезных показателей, чем большой набор показателей с сомнительной полезностью.

6.1. Почему от этой попытки ожидается успех

Как отмечено в предыдущем параграфе, одной из основных проблем предыдущего реестра был слишком общий характер включённых в него показателей, делавших их бесполезными. Этот документ задаёт более строгие критерии для регистрации показателей производительности (см. раздел 5) и экспертизу группой Performance Metrics Expert, которые предоставят рекомендации для оценки корректности спецификации Performance Metric.

Другим важным различием является то, что у нового реестра имеется хотя бы 1 очевидный пользователь – модель и протокол LMAP. Поскольку протокол LMAP будет использовать значения Performance Metrics Registry в своей работе, это фактически помогает проверить корректность определения метрики. В частности, поскольку ожидается, что LMAP Control Protocol позволит контроллеру запрашивать у Measurement Agent проведение измерений с использованием метрики путём встраивания Performance Metrics Registry Identifier в протокол. Метрика и методы будут указаны правильно, если они определены достаточно хорошо, чтобы было возможно (и практично) реализовать их в агентах измерения. Этого не удалось в прежней попытке, где запись реестра с неопределённым Type-P (раздел 13 в [RFC2330]) позволяла результатам измерений существенно различаться.

7. Определение реестра метрик производительности

Реестр Performance Metrics применим к показателям производительности при активных и пассивных измерениях, а также для иных форм измерений показателей производительности. Каждая категория измерений имеет уникальные свойства, поэтому некоторые из описанных столбцов применимы не ко всем категориям показателей. Т таких случаях в столбце следует указывать значение N/A (неприменимо). Однако такое значение недопустимо использовать в столбцах Identifier, Name, URI, Status, Requester, Revision, Revision Date, Description. В будущем новые категории показателей могут потребовать новых столбцов и такое добавление станет признанной формой расширения реестра. В спецификации нового столбца должны даваться общие рекомендации по заполнению для имеющихся записей.

Столбцы Performance Metrics Registry определены ниже и группируются в категории (Category) для упрощения использования реестра. Категории описаны в параграфах 7.x, столбцы – в параграфах 7.x.y. Приведённый ниже рисунок показывает их организацию. Каждая запись (строка) реестра даёт полное описание показателя производительности.

Каждый столбец является элементом контрольного списка и помогает избежать пропусков при регистрации и рецензировании (Expert Review) [RFC8126].

Формат категорий и столбцов реестра показан ниже.

       Категория
       ------------------...
       Столбец |Столбец |...

   Сводка
   ---------------------------------------------------------------
   Идентификатор| Имя | URI |Описание| Ссылка |Контролёр| Версия |
                |     |     |        |        |изменений|

   Определение показателя
   ----------------------------------------------
   Ссылка на определение|Фиксированные параметры|

   Метод измерения
   ---------------------------------------------------------------------
   Ссылка на | Генерация  | Фильтр  | Распределение| Рабочие    | Роль |
   метод     | потока     | трафика | выборки      | параметры  |      |
             | пакетов    |
   Вывод
   -----------------------------------------
   Тип  | Ссылка на  |Единицы| Калибровка  |
        | определение|       |             |

   Административная информация
   --------------------------------------
   Статус |Запросчик|Выпуск|дата выпуска|

   Комментарии и примечания
   ------------------------


Пустой шаблон реестра приведён в разделе 11.

7.1. Сводная категория

7.1.1. Идентификатор

В этом столбце указываются числовые идентификаторы зарезервированных показателей производительности. Идентификатор каждого зарегистрированного показателя должен быть уникальным. Отметим, что при пересмотре метрики по процедуре, описанной в параграфе 8.2 новая запись в Performance Metrics Registry сохраняет прежний идентификатор.

Идентификаторами зарегистрированных показателей производительности являются неограниченные целые числа от 0 до ∞. Идентификатор 0 следует оставить резервным. Идентификаторы от 64512 до 65535 резервируются для приватного и экспериментального использования и могут оказаться неуникальными.

При добавлении нового показателя в Performance Metrics Registry агентству IANA следует выделять наименьший доступный идентификатор. Если Performance Metrics Expert при рецензировании увидел причину выделить конкретный числовой идентификатор (возможно с пропуском некоторых значений), этому эксперту нужно уведомить IANA о таком решении.

7.1.2. Имя

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

Имена состоят из показанных ниже элементов, разделённых символом подчёркивания «_»

      MetricType_Method_SubTypeMethod_... Spec_Units_Output

MetricType

Комбинация связанных с направлением свойств и измеряемых показателей (указанных в таблице 1 или иных).

Таблица 1.

RTDelay

Round-Trip Delay – круговая задержка

RTDNS

Response Time Domain Name Service – время отклика DNS

RLDNS

Response Loss Domain Name Service – потери откликов DNS

OWDelay

One-Way Delay – задержка в одном направлении

RTLoss

Round-Trip Loss – круговые потери

OWLoss

One-Way Loss – потери в одном направлении

OWPDV

One-Way Packet Delay Variation – вариации односторонней задержки

OWIPDV

One-Way Inter-Packet Delay Variation – вариации односторонней задержки между пакетами

OWReorder

One-Way Packet Reordering – одностороннее нарушение порядка пакетов

OWDuplic

One-Way Packet Duplication – одностороннее дублирование пакетов

OWBTC

One-Way Bulk Transport Capacity – транспортная «ёмкость» в одном направлении

OWMBM

One-Way Model-Based Metric – односторонняя метрика на основе модели

SPMonitor

Single-Point Monitor – одноточечный монитор

MPMonitor

Multi-Point Monitor – многоточечный монитор

Method

Один из методов, определённых в [RFC7799], таких, что указаны в таблице 2, или иных.

Таблица 2.

Active

Зависит от выделенного потока измерительных пакетов и наблюдений за потоком, как указано в [RFC7799]

Passive

Зависит «исключительно» от наблюдения за одним или несколькими потоками, как описано в [RFC7799]

HybridType1

Наблюдение за одним потоком, сочетающее активные и пассивные методы, как описано в [RFC7799]

HybridType2

Наблюдение за несколькими потоками, сочетающее активные и пассивные методы, как описано в [RFC7799]

Spatial

Пространственная метрика, описанная в [RFC5644]

SubTypeMethod

Один или несколько субтипов, дополнительно описывающих свойства записи, как показаны в таблице 3, или иных.

Таблица 3.

ICMP

Internet Control Message Protocol – протокол управляющих сообщений Internet (ICMP)

IP

Internet Protocol – протокол IP

DSCPxx

xx заменяется кодом Diffserv

UDP

User Datagram Protocol – протокол UDP

TCP

Transport Control Protocol – протокол TCP

QUIC

QUIC transport protocol – транспортный протокол QUIC

HS

Hand-Shake, such as TCP’s 3-way HS – согласование, такое как 3-этапное согласование TCP

Poisson

Генерация пакетов с распределением Пуассона

Periodic

Периодическая генерация пакетов

SendOnRcv

Отправитель сохраняет один пакет, находящийся в пути, отправляя пакет по доставке предыдущего.

PayloadxxxxB

xxxx заменяется целым числом октетов или 8-битовых байтов в поле данных (Payload)

SustainedBurst

Тест «ёмкости» для худшего случая

StandingQueue

Проверка поведения очереди при наличии «пробки»

Значения SubTypeMethod разделяются дефисом (-), они относятся к одному элементу и порядок не имеет значения в плане уникальности Name.

Spec

Неизменяемый идентификатор документа с указанием раздела в нем. Для RFC указывается номер и раздел в RFC для этой записи реестра в форме RFCXXXXsecY, например, RFC7799sec3.3

Units

Единицы измерения для вывода, такие, как указано в таблице 4, или иные.

Таблица 4.

Seconds

Секунды

Ratio

Безразмерно

Percent

Процентная доля (значение, умноженное на 100%)

Logical

1 или 0

Packets

Пакеты

BPS

Бит/с

PPS

Пакет/с

EventTotal

Безразмерный счётчик

Multiple

Несколько типов единиц

Enumerated

Список результатов

Unitless

Безразмерные единицы

Output

Тип вывода с результатами измерений, такой, как указано в таблице 5, или иной.

Таблица 5.

Singleton

Одиночное значение

Raw

Множество одиночных значений (singleton)

Count

Счётчик

Minimum

Минимум

Maximum

Максимум

Median

Медиана

Mean

Среднее значение

95Percentile

95-й процентиль

99Percentile

99-й процентиль

StdDev

Стандартное отклонение

Variance

Вариация

PFI

Прошло, отказ, нет результата

FlowRecords

Описание наблюдаемых потоков

LossRatio

Отношение числа потерянных пакетов к общему числу (<=1)

Примером может служить представленное в разделе 4 [RFC8912] имя RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile.

Для частных реестров, придерживающихся описанного здесь формата, следует использовать префикс Priv_ или иное имя, не приводящее к неожиданным конфликтам (см. раздел 10). Записи приватных реестров обычно не связаны с RFC, поэтому элемент Spec не имеет чёткой интерпретации.

7.1.3. URI

Столбец URI должен содержать URL [RFC3986] с однозначным указанием местоположения Metric Entry, доступного через Internet. URL указывает файл, содержащий понятные человеку сведения из одной записи реестра. В URL нужно указывать файл (предпочтительно в формате HTML) с URL, указывающими RFC в формате HTML или иные спецификации. Эти файлы для разных записей можно легко редактировать и применять при подготовке новых записей. Точная форма URL для каждого файла и сам файл будут определяться IANA и храниться на сайте https://www.iana.org/. В разделе 4 [RFC8912] и других разделах этого документа содержатся ссылки на файлы HTML.

7.1.4. Описание

Описание Registered Performance Metric является письменным представлением отдельной записи реестра показателей производительности. Оно дополняет Registered Performance Metric Name, чтобы помочь пользователям реестра выбрать подходящие показатели производительности.

7.1.5. Ссылка

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

7.1.6. Контролёр изменений

В этой записи указывается лицо (организация), ответственное за одобрение пересмотра записи, и в неё нужно включать контактные данные (конкретных людей, если это приемлемо).

7.1.7. Версия (формата реестра)

В этом столбце указывается номер версии формата реестра на момент регистрации Performance Metric. Для формата, соответствующего этому документу, должна указываться версия 1.0. Новый документ RFC, меняющий формат реестра, будет указывать для формата новый номер. Номер версии не следует менять, пока Registry Entry не будет обновлена в соответствии с новым форматом (по процедурам из раздела 8).

7.2. Категории определения метрики

Эта категория включает столбцы для всех деталей, требуемых для определения метрики, включая ссылку на неизменяемый документ и значения входных параметров, называемых фиксированными (Fixed Parameters), которые не задаются в определяющем документе, но имеют конкретные значения, указанные Performance Metric.

7.2.1. Ссылка на определение

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

7.2.2. Фиксированные параметры

Фиксированными (Fixed) называют параметры, значения которых должны быть указаны в Performance Metrics Registry. Измерительная система использует эти значения.

Если показатели предоставляют список параметров как часть своего описательного шаблона, подмножество этих параметров обозначается как Fixed Parameters. В качестве примера для активных показателей (Active Metric) фиксированные параметры задают все или большинство соглашений модели IPPM «пакеты Type-P», как описано в [RFC2330], таких как транспортный протокол, размер поля данных (payload), TTL и т. п. Примером для пассивных показателей (Passive Metric) является расчёт потерь RTP, основанный на проверке принадлежности пакета протоколу RTP, который представляет собой проверку нескольких пакетов, контролируемую переменной MIN_SEQUENTIAL, как указано в [RFC3550]. Изменение MIN_SEQUENTIAL может менять отчёт о потерях и эту переменную можно установить как фиксированный параметр.

Параметры должны иметь чётко заданные имена. Для человека предпочтителен стиль «обратного отступа» (hanging-indent) и имена и определения параметров, которые не указаны в спецификации эталонного метода, должны включаться в этот столбец (или в столбец Runtime Parameters).

Параметры должны иметь чётко заданный формат данных.

Параметры, являющиеся фиксированными для одной записи Performance Metrics Registry, могут быть обозначены как рабочие (Runtime) для другой записи реестра.

7.3. Категория метода измерения

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

7.3.1. Ссылка на метод

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

7.3.2. Генерация потока пакетов

Этот столбец применяется для показателей производительности, которые используют в методе измерения генерацию трафика для активных или иных измерений. Генерируемый трафик называется потоком (stream) и этот столбец описывает его характеристики. Каждая запись в этом столбце содержит указанные ниже поля.

Value

Имя дисциплины планирования пакетов.

Reference

Спецификация, где заданы параметры потока.

Для генерации потока пакетов могут потребоваться такие параметры, как средняя скорость передачи пакетов и значение отсечки распределения для патоков с распределением Пуассона для межпакетных интервалов. Если такие параметры нужны, их следует включать в столбец Fixed Parameters или Runtime Parameters, в зависимости от того, являются они фиксированными или служат входными данными для показателя.

Простейшим примером спецификации потока является одиночное (singleton) планирование (см. [RFC2330]), где выполняется одно атомарное измерение. Каждое такое измерение может включать передачу одного (например, запроса DNS) или нескольких (например, запрос web-страницы) пакета. Другие потоки поддерживают серии атомарных измерений, где поток пакетов следует планированию, задающему интервал между передачей пакетов, и атомарные измерения оценивают время между получением последовательных пакетов (например, измерение вариаций межпакетного интервала). Возможны более сложные потоки и измерительные взаимодействия. В метриках IPPM применяются в основном два типа потоков: (1) потоки с распределением Пуассона, описанные в [RFC2330] и (2) периодические потоки, описанные в [RFC3432]. Оба этих типа имеют свои уникальные параметры и соответствующий набор имён параметров следует включать в столбец Fixed Parameters или Runtime Parameters.

7.3.3. Фильтр трафика

Эта колонка применяется к показателям производительности с наблюдением пакетов, проходящих через устройство с агентом измерения, т. е. не обязательно адресованных этому агенту. Это относится, в частности, к пассивным показателям. Фильтр задаёт измеряемый трафик и включает значения (диапазоны) полей протокола, таких как адреса и идентификаторы потоков или сессий.

Сам фильтр трафика зависит от потребностей показателя и баланса потребностей оператора в измерениях и требований к приватности пользователей Механизмами для установки критериев фильтрации могут быть пакетные фильтры BPF (Berkeley Packet Filter) или фильтры совпадения свойств PSAMP (выборка пакетов) [RFC5475], которые применяют IPFIX [RFC7012]. Примером строки BPF для сопоставления трафика TCP/80 с адресом сети удалённого получателя 192.0.2.0/24 является строка “dst net 192.0.2.0/24 and tcp dst port 80”. Более сложные системы фильтрации могут использовать сопоставление на основе глубокой инспекции пакетов (Deep Packet Inspection или DPI).

Traffic Filter включает указанную ниже информацию.

Type

Тип используемого фильтра, например, BPF, PSAMP, правило и т. п., как указано в нормативной ссылке.

Value

Фактический набор правил фильтрации.

7.3.4. Распределение выборки

Распределение выборки выбирает из всех пакетов, соответствующих Traffic Filter, один или несколько пакетов, фактически используемых для измерения. Один из возможных вариантов – all предполагает учёт всех прошедших фильтр пакетов, но могут применяться и иные стратегии выборки. Столбец включает указанные ниже сведения.

Value

Имя распределения выборки.

Reference definition

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

Для распределения выборки могут потребоваться параметры. В этом случае их следует в столбец Fixed Parameters или Runtime Parameters в зависимости от того, фиксированы они или служат входными данными для метрики.

Фильтры PSAMP описаны в «Sampling and Filtering Techniques for IP Packet Selection» [RFC5475], а в работе «A Framework for Packet Selection and Reporting» [RFC5474] представлены базовые сведения о фильтрации. Параметры распределения выборки могут быть заданы в соответствии с «Information Model for Packet Sampling Exports» [RFC5477] и процессом, описанным в «Flow Selection Techniques» [RFC7014].

7.3.5. Рабочие параметры

В отличие от фиксированных, рабочие параметры не меняют фундаментальной природы измерения и их значения не указываются в Performance Metrics Registry. Они остаются в реестре как переменные, чтобы помочь разработчикам и пользователям измерительной системы. Значения параметров задаются при исполнении через настройку системы измерения и указываются в результатах для полноты контекста.

Если метрика представляет список параметров как часть описательного шаблона, часть этих параметров помечается как рабочие (Runtime).

Параметры должны иметь чётко заданные имена. Для человека предпочтителен стиль «обратного отступа» (hanging-indent) и имена и определения параметров, которые не указаны в спецификации эталонного метода, должны включаться в этот столбец (или в столбец Runtime Parameters).

Формат данных для каждого параметра Runtime должен указываться в этом столбце для упрощения реализации и управления системами измерения. Например, параметры, включающие адрес IPv4, можно представлять 32-битовым целым числом (двоичное значение в кодировке base64) или в формате ip-address, заданном в [RFC6991]. Используемое фактически представление должно быть указано явно для каждого рабочего параметра. Адреса и опции IPv6 должны быть включены, чтобы зарегистрированные показатели производительности можно было использовать для этого семейства адресов. Допускается указание иных адресных семейств.

Примеры рабочих параметров включают адреса IP, обозначения точек измерения, время начала и завершения, а также иные сведения, важные для метода измерений.

7.3.6. Роль

В некоторых методах измерения может задаваться несколько ролей. Например при активном измерении односторонней задержки один агент измерения генерирует пакеты, а другой принимает их. В этом столбце указываются имена ролей (Role) для данной записи. В примере с односторонней задержкой в столбце следует указать две записи – по одной для каждой роли (Source и Destination). Когда агенту измерения задана роль Source для показателя односторонней задержки, этот агент знает, что ему нужно генерировать пакеты. Значения для этого поля определяются эталонным методом измерения (Reference Method of Measurement), при этом часто используются сокращённые обозначения ролей, такие как Src.

Если в столбце Role записи реестра указано несколько ролей, значение Role нужно считать рабочим (Runtime) параметром и представлять для выполнения. Следует отметить, что в схеме LMAP [RFC7594] роли отличаются от других параметров Runtime.

7.4. Категория вывода

Для записей, включающих потоки и множество одиночных (singleton) измерений в этом столбце может быть указан тип статистики для представления результата одним значением. Если выводится полный набор полученных одиночных результатов (singleton) это тоже указывается здесь.

Некоторые показатели включают 1 конкретный тип статистики в эталонном определении метрики, тогда как другие позволяют выводить несколько типов статистики.

7.4.1. Тип

В этом столбце указывается имя типа вывода, определяющего 1 тип результата для данного процесса измерения. Это могут быть необработанные (raw) результаты (время отправки пакетов и одиночные измерения показателя) или какой-либо тип статистики. Спецификация типа вывода должна задавать формат вывода. В некоторых системах спецификация формата будет упрощать как реализацию измерений, так и задачи сбора и хранения результатов. В случаях, когда для одного измерения требуется два типа статистики (например, среднее значение процентиля X и Raw), должен быть задан новый тип вывода (Xth percentile mean AND Raw). Список типов вывода приведён в параграфе 7.1.2.

7.4.2. Ссылка на определение

В этом столбце приводятся указатели на спецификации, где определён тип и формат вывода.

7.4.3. Единицы измерения

Результаты измерений должны указываться с использованием той или иной стандартной размерности или в единиц измерения. Столбец указывает эти единицы.

При сборе одиночных измерений (см. определения в разделе 11 [RFC2330]) эта запись задаёт единицы для каждого измеренного значения.

7.4.4. Калибровка

Некоторые спецификации методов измерения включают возможность выполнить калибровку ошибок (например, параграф 3.7.3 в [RFC7679]). В записи реестра это поле указывает метод калибровки метрики и, когда это доступно, измерительной системе следует выполнять калибровку по запросу и указывать в выводе, что результат относится к калибровке. Калибровка на месте может быть организована с помощью внутренней петли (loopback), включающей как можно большую часть измерительной системы, выполняющей нужные манипуляции с адресами и обеспечивать ту или иную изоляцию (например, вносить детерминированную задержку) для предотвращения конфликтов между приёмными и передающими интерфейсами. Таким способом можно получить часть характеристик случайных и систематических ошибок.

Для измерений односторонней задержки калибровка ошибок должна включать оценку синхронизации внутренних часов (они предоставляют временные метки для измерений) с внешним источником. На практике требуется знать смещение часов у отправителя и получателя для оценки систематической ошибки в результате неидеальной синхронизации (смещение часов сглаживается, поэтому случайные вариации обычно не влияют на результат).

Калибровку по внутренней петле и синхронизацию часов можно использовать для оценки «доступной точности» выходных единиц измерения (Output Metric Unit). Например, повторяющиеся измерения задержки на внутренней петле покажут часть погрешности результата, связанную с системным шумом.

7.5. Административная информация

7.5.1. Статус

Эта запись указывает статус спецификации этой зарегистрированной метрики производительности. Разрешены значения Current (действует), Deprecated (отменено), Obsolete (устарело). Вновь опубликованные записи Registered Performance Metrics имеют статус Current.

7.5.2. Запросчик

Эта запись указывает сторону, запросившую Registered Performance Metric, которой может быть документ (например, RFC) или человек.

7.5.3. Выпуск

Запись указывает номер выпуска (revision number) Registered Performance Metric, начиная с 0 для записи в момент её первоначальной регистрации. Для каждого нового выпуска значение номера увеличивается. Если новый выпуск не совместим с предшествующими, выполняются требования параграфа 8.3.

7.5.4. Дата выпуска

Эта запись указывает дату принятия последнего выпуска Registered Performance Metric. Определение даты выпуска нужно отдавать IANA и экспертам-рецензентам (Performance Metrics Expert).

7.6. Комментарии и заметки

Помимо предоставления дополнительных сведений, которых нет в других категориях, эта открытая категория (1 столбец) позволяет решать непредвиденные вопросы путём простого обновления этой информационной записи.

8. Процессы управления группой Performance Metrics Registry

После того как показатель или набор показателей определены для данного применения, запись-кандидат для Performance Metrics Registry, подготовленную в соответствии с разделом 7, следует представить в IANA для рецензирования экспертами, как описано ниже. Этот процесс также применяется при изменении Performance Metrics Registry Entry, например, при пересмотре или отмене, как описано в этом разделе.

Желательно, чтобы авторы записи-кандидата обратились за рецензией в соответствующую рабочую группу IETF или предложили возможность обзора в почтовой рассылке группы.

8.1. Добавление новой метрики в Performance Metrics Registry

Запросы на добавление Registered Performance Metric в реестр показателей производительности нужно представлять в агентство IANA, которое пересылает их назначенной IESG группе экспертов (Performance Metrics Experts). Рецензенты рассматривают запрос в соответствии с процедурой Specification Required [RFC8126], заданной для них. Эксперты рассматривают запрос на предмет соответствия данному документу и другим RFC, связанным с показателями производительности, а также текущему набору зарегистрированных показателей производительности. Наиболее эффективно начать представление заявки с подготовки проекта документа (Internet-Draft), содержащего предлагаемую для реестра запись на основе шаблона из разделе 11 – такой подход позволит воспользоваться преимуществами обычной обработки IETF для Internet-Draft (включая перевод в HTML).

Представление в IANA может происходить в процессе рецензирования IESG (ведущего к IETF Standards Action), где рассматривается документ Internet-Draft, предлагающий один или несколько регистрируемых показателей производительности для добавления в Performance Metrics Registry, включая текст предложенных для регистрации показателей производительности.

Если будущий RFC включает Performance Metric и предлагаемую запись Performance Metrics Registry, но рецензия Performance Metrics Expert указывает, что не выполняется один или несколько критериев из раздела 5, предлагаемая запись Performance Metrics Registry должна быть удалена из текста. Как только станет ясно, что предлагаемая запись соответствует критериям раздела 5, эту запись следует представить в IANA для оценки с участием экспертов Performance Metrics с целью регистрации записи.

Авторам предлагаемых Registered Performance Metric следует проверять соответствие спецификациям этого документа перед представлением в IANA.

Хотя бы один из Performance Metrics Expert должен выполнить своевременное рецензирование предложенной записи. Если запрос принимается, эксперты по показателям производительности представляют своё одобрение в IANA, а IANA обновляет реестр Performance Metrics. Если запрос неприемлем, эксперты могут координировать свои действия с запрашивающей стороной для изменения запроса в соответствии с требованиями. В иных случаях агентству IANA нужно координировать решение вопроса от имени эксперта. Эксперты Performance Metrics могут отклонить явно необоснованные или неприемлемые запросы на изменение, но такие случаи представляются маловероятными.

Если предложенная метрика в значительной степени уникальна, для её подобающего описания может потребоваться новый реестр элементов (Name Element Registry) или (более вероятно) новый элемент в существующем реестре Name Element Registry. Такое предложение является частью запроса на добавление новой метрики, поэтому оно проходит те же процедуры рецензирования и одобрения в IANA.

Решения экспертов Performance Metrics могут быть обжалованы в соответствии с разделом 10 в [RFC8126].

8.2. Совместимый с прежним выпуск Registered Performance Metric

Запросы на пересмотр разрешаются лишь в тех случаях, когда запрошенные изменения совместимы с поддерживающими прежний вариант реализациями Performance Metrics Registry Entry (backward compatibility), т. е. запись с меньшим номером версии, но теми же значениями Identifier и Name.

Поле Status в Performance Metrics Registry указывает текущий статус записи Current, Deprecated или Obsolete. Термин deprecated применяется в тех случаях, когда запись заменяется совместимым с прежней версией выпуском, как описано в этом параграфе или несовместимым с прежним выпуском (параграф 8.3).

Не задано политики пересмотра записей Performance Metric в реестре или исправления ошибок в них. Говоря точнее, изменения и отмены (deprecation) в Performance Metrics Registry не приветствуются и их следует избегать, когда это возможно. Однако при неизбежности изменения этот параграф определяет его внесение.

Пересмотр инициируется отправкой определения кандидата в Registered Performance Metric агентству IANA в соответствии с параграфом Section 8.1 с указанием имеющейся записи Performance Metrics Registry и разъяснением причин и способа пересмотра имеющейся записи.

Основным требованием при определении процедур управления изменениями в уже зарегистрированных показателях производительности является предотвращение проблем совместимости. Эксперты Performance Metrics должны заботиться прежде всего о поддержании совместимости.

Изменения в зарегистрированный показатель производительности могут вноситься лишь при обеспечении совместимости. Запрашиваемые изменения, которые не могут обеспечить взаимодействие с имеющимися совместимыми реализациями, должны приводить к созданию новой записи Registered Performance Metric (с новым значением Name, где изменена часть RFCXXXXsecY) и возможно к объявлению прежней метрики устаревшей (deprecated).

Изменение Registered Performance Metric нужно считать совместимым с прежними (backward compatible), когда выполняется хотя бы одно из приведённых ниже условий.

  1. Изменение включает исправление ошибок и очевидно является лишь редакторской правкой.

  2. Исправляется неоднозначность в определении Registered Performance Metric, которая может вызывать достаточно серьёзные проблемы использования Registered Performance Metric.

  3. Добавляется пропущенная в определении показателя информация, не меняющая смысла определения (например, явно задаётся семантика числового значения без смены семантики типа данных).

  4. Выполняется согласование с внешней ссылкой, которая указывает на изменённый документ.

  5. Текущий формат реестра пересмотрен с добавлением столбца, который не имеет отношения к текущей Registered Performance Metric (т. е. в текущей метрике этот столбец содержал бы значение Not Applicable).

Если пересмотр Performance Metric сочтён допустимым и совместимым с прежней версией экспертами Performance Metrics в соответствии с правилами этого документа, IANA следует внести изменения в Performance Metrics Registry. Инициатор изменения добавляется к запросившему исходную регистрацию лицу или документу в Performance Metrics Registry. Имя пересмотренного показателя производительности, включая часть RFCXXXXsecY, нужно сохранять неизменным, даже при изменении реестра в результате IETF Standards Action. В пересмотренной записи реестра следует указывать новый неизменяемый документ, такой как RFC. Для других органов стандартизации может потребоваться ссылка на конкретную спецификацию с указанием даты в соответствующей категории и столбце.

Каждый зарегистрированный показатель производительности в Performance Metrics Registry имеет номер выпуска и нумерация начинается с 0. При каждом изменении Registered Performance Metric в соответствии с описанным процессом номер выпуска увеличивается на 1.

При восприятии изменённого показателя Registered Performance Metric в Performance Metrics Registry дата последнего выпуска помещается в столбец Revision Date для зарегистрированного показателя.

Когда это применимо, в столбцы Comments или Remarks следует включать дату и такие изменения не считаются пересмотром в соответствии с описанным здесь процессом.

Прежние версии обновляемых записей реестра сохраняются для архивных целей. Поля этих записей (включая Revision Date) не изменяются, но значение поля Status нужно заменить на Deprecated.

Этот процесс не следует считать позволяющим экспертам Performance Metrics отвергать согласование с IETF. В частности, любые зарегистрированные показатели производительности, добавленные в Performance Metrics Registry с согласия IETF требуют согласования их пересмотра или отмены с IETF.

8.3. Несовместимый с прежними выпуск Registered Performance Metric

В этом параграфе описана процедура несовместимого с прежним выпуском обновления Registered Performance Metric. Зарегистрированная метрика может быть отменена (deprecated) и заменена в 2 случаях.

  1. Определение Registered Performance Metric содержит ошибку или недостаток, которые нельзя изменить в соответствии с параграфом 8.2. Совместимый с прежним выпуск Registered Performance Metric.

  2. Отмена вызвана отменой документа, указанного ссылкой, которая была принята по действующей процедуре.

Запрос на отмену передаётся в агентство IANA, которое направляет его на рецензию экспертам Performance Metrics. При отмене Performance Metric описание метрики в Performance Metrics Registry должно быть обновлено с разъяснением отмены, а также ссылкой на новую метрику, заменяющую отменённую.

Когда несовместимая с прежней новая Performance Metric заменяет объявленную (сейчас) отменённой метрику, номер выпуска в новой Registered Performance Metric увеличивается по сравнению с имевшимся в отменённой номером и указывается текущая дата в поле Revision Date новой записи.

При преднамеренном использовании отменённой метрики производительности соответствующему приложению следует делать запись в системный журнал или выводить понятное человеку предупреждение.

Недопустимо снова использовать имя и идентификатор отменённой метрики.

Отменённые записи сохраняются без изменения столбцов категории Administrative, за исключением поля Status, в котором указывается значение Deprecated.

8.4. Устаревшие записи реестра

Имеющиеся в реестре записи могут устаревать по любой из указанных ниже причин.

  1. Обнаружение существенной ошибки в Registered Performance, исправлять которую бессмысленно.

  2. Одна или несколько важных ссылок указывает на документы или их разделы, которые признаны устаревшими.

  3. Иные причины, доведённые до сведения IANA и экспертов реестра.

При объявлении записи Performance Metric Registry устаревшей (obsolete) описание Performance Metric в реестре обновляется с разъяснением причин признания записи устаревшей и отсутствия замены (отмена – Deprecation записи всегда включает её замену).

Устаревшие записи хранятся без изменения столбцов категории Administrative за исключением указания в поле Status значение Obsolete.

8.5. Версия формата реестра и её изменение

Версия формата реестра, определённая этим документом, имеет значение 1.0 и записи-кандидаты, соответствующие этому документу, должны использовать значение 1.0.

Формат реестра может быть обновлён публикацией RFC с новым форматом (Standards Action).

При создании или пересмотре зарегистрированной метрики производительности используется свежая версия Registry Format.

Предусмотрена лишь одна форма расширения реестра.

Добавление столбцов или категорий и столбцов для учёта непредвиденных аспектов новых измерений и категорий показателей.

При расширении Performance Metrics Registry таким способом номер версии будущих записей, соответствующих расширению, нужно инкрементировать (в первом или втором элементе, в зависимости от значимости расширения).

9. Вопросы безопасности

Этот документ определяет структуру реестра и сам по себе не оказывает влияния на безопасность Internet. Определение показателей производительности для этого реестра может создавать некоторые проблемы безопасности, но в указанные обязательными ссылками документы следует включать разделы по вопросам безопасности и такие определения следует рецензировать с учётом безопасности, если эти вопросы не рассмотрены ни в одном из связанных с метрикой стандартов.

Агрегированные результаты для показателей производительности, описанных в этом реестре, могут раскрывать данные о топологии сети, которые могут считаться конфиденциальными. В таких случаях следует применять механизмы контроля доступа.

10. Взаимодействие с IANA

С учётом предыстории и описанных выше процессов, агентство IANA предприняло действия, рассмотренные ниже.

10.1. Группа реестров

Новая группа реестров названа Performance Metrics. В этом документе она обозначается как Performance Metrics Group или Registry Group. Все регистрации доступны по ссылке https://www.iana.org/assignments/performance-metrics.

Для ясности отметим, что в этом документе и [RFC8912] используются указанные в таблице 6 соглашения для обозначения различных реестров IANA, связанных с Performance Metrics.

Таблица 6.

 

RFC 8911 и RFC 8912

Web-страница IANA

Название страницы

Performance Metrics Group

Performance Metrics

Основной реестр

Performance Metrics Registry

Performance Metrics Registry

Строка реестра

Performance Metrics Registry Entry

Регистрация (и шаблон)

 

   Registration Procedure: Specification Required
   Reference: RFC 8911
   Experts: Performance Metrics Experts

10.2. Элементы имён показателей производительности

Этот документ задаёт и заполняет реестры для Performance Metric Name Elements. Имя, назначенное записи Performance Metric Registry состоит из нескольких элементов, разделённых символом подчёркивания (_) в порядке заданном параграфом 7.1.2. Агентство IANA создало перечисленные ниже реестры с текущим набором возможностей для каждого элемента в Performance Metric Name.

MetricType
Method
SubTypeMethod
Spec
Units
Output

При создании агентство IANA заполнило Registered Performance Metrics Name Elements с использованием списка значений для каждого Name Element, указанного в параграфе 7.1.2. Регистр символов в именах имеет значение.

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

Кандидат в Metric Entry предлагает набор значений для элементов своего имени. Этот набор рассматривается IANA и экспертами реестра. Возможно, что кандидат предлагает новое значение Name Element (отсутствует в текущем списке возможных) или даже новый элемент имени. Такие новые назначения администрируются IANA по процедуре Specification Required [RFC8126], которая включает Expert Review (рецензия одного из экспертов Performance Metrics, назначаемых IESG по рекомендациям руководителей направления Transport).

10.3. Новый реестр Performance Metrics

Этот документ задаёт реестр Performance Metrics Registry, содержащий в категории Summary столбцы:

Identifier;
Name;
URI;
Description;
Reference;
Change Controller;
Version.

Описание этих столбцов и дополнительные сведения представлены в шаблоне записей реестра (категории и столбцы), а определения приведены разделе 7.

Идентификатор 0 следует оставлять резервным, выделяя в качестве уникальных идентификаторов Registered Performance Metric целочисленные значения от 1 до бесконечности. Диапазон 64512 – 65535 резервируется для приватного и экспериментального использования и значения из этого диапазона могут оказаться неуникальными. При добавлении в реестр новой метрики агентству IANA следует выбирать наименьшее доступное значение Identifier для новой записи Registered Performance Metric. Если выполняющий рецензирование эксперт Performance Metrics увидит причины выделить конкретное значение Identifier, возможно создающее временный пропуск в нумерации, эксперту нужно уведомить IANA об этом решении.

Имена с префиксом Priv_ резервируются для приватного использования и не рассматриваются для регистрации. Определение элементов столбца Name дано в разделе 7.

В столбце URI указывается идентификатор URL для каждой заполненной записи реестра. Текст записи нужно приводить в формате HTML, чтобы читатель мог пользоваться (как с Internet-Draft в формате HTML) ссылками на упомянутые разделы RFC или иных неизменяемых документов.

В столбце указывается номер RFC, обозначение спецификации, одобренной другим органом стандартизации, или иной неизменяемый документ.

Новые назначения в Performance Metrics Registry администрируются IANA по процедуре Specification Required [RFC8126] (включает Expert Review, т. е. рецензию одного или нескольких экспертов, в данном случае – Performance Metrics Experts, назначаемых IESG по рекомендациям руководителей направления Transport) или Standards Action. Эксперты первоначально могут быть выбраны из числа руководителей рабочих групп, редакторов документов и членов Performance Metrics Directorate, а также среди других специалистов.

Расширения Performance Metrics Registry требуют процедуры IETF Standards Action. Предусмотрен лишь один способ расширения реестра, указанный ниже.

  • Добавление столбцов или категорий и столбцов для учёта непредвиденных аспектов новых измерений и категорий показателей.

При расширении Performance Metrics Registry таким способом номер версии будущих записей, соответствующих расширению, нужно инкрементировать (в первом или втором элементе, в зависимости от значимости расширения).

11. Пустой шаблон реестра

В этом разделе представлен пустой шаблон для оказания помощи при подготовке к регистрации записи в IANA.

11.1. Summary

Эта категория включает индексы Registry Entry в форме идентификатора (element ID) и имени метрики (Metric Name).

11.1.1. ID (Identifier)

Целочисленный идентификатор метрики.

11.1.2. Name

Имя, соответствующее соглашению об именовании показателей.

11.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/ … <Name>.

11.1.4. Description

Описание метрики.

11.1.5. Reference

Указывается RFC или иная спецификация одобренного кандидата в Registry Entry.

11.1.6. Change Controller

Сведения об организации, отвечающей за одобрение пересмотра Registry Entry (включая контактные данные людей, если это приемлемо).

11.1.7. Version (of Registry Format)

11.2. Metric Definition

Эта категория включает столбцы для всех требуемых деталей определения метрики, включая ссылку на неизменяемый документ и значения входных параметров, называемых фиксированными (Fixed Parameters).

11.2.1. Reference Definition

Полная библиографическая ссылка на неизменяемый документ с указанием при необходимости разделов и пояснений.

11.2.2. Fixed Parameters

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

11.3. Method of Measurement

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

11.3.1. Reference Method

Ссылки на соответствующие неизменяемые разделы документов и иные сведения.

11.3.2. Packet Stream Generation

Список параметров генерации пакетов и ссылки на документы (с разделами) при необходимости.

11.3.3. Traffic Filtering (Observation) Details

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

11.3.4. Sampling Distribution

Детали распределения или его отличие от фильтра.

11.3.5. Runtime Parameters and Data Format

Рабочие (Runtime) параметры, которые должны быть заданы и настроены в системе измерения, а также указаны в отчёте для полноты контекста. Параметры указываются с форматом данных.

11.3.6. Roles

Список имён ролей для метода измерения.

11.4. Output

Эта категория задаёт детали вывода для использующих метрику измерений.

11.4.1. Type

Имя типа вывода – необработанные (raw) результаты или определённая статистика.

11.4.2. Reference Definition

Эталонный формат данных для каждого типа результатов.

11.4.3. Metric Units

Единицы, используемые в результатах измерения и их спецификация.

11.4.4. Calibration

Сведения о калибровке.

11.5. Administrative Items

Эта категория содержит административные сведения.

11.5.1. Status

Статус метрики (Current или Deprecated).

11.5.2. Requester

Имя запрашивающего лица, номер RFC и т. п.

11.5.3. Revision

Номер выпуска, начиная с 0.

11.5.4. Revision Date

Дата в формате YYYY-MM-DD.

11.6. Comments and Remarks

Дополнительные сведения для этой записи.

12. Литература

12.1. Нормативные документы

[RFC2026] Bradner, S., “The Internet Standards Process – Revision 3”, BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.

[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>.

[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>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC5644] Stephan, E., Liang, L., and A. Morton, “IP Performance Metrics (IPPM): Spatial and Multicast”, RFC 5644, DOI 10.17487/RFC5644, October 2009, <https://www.rfc-editor.org/info/rfc5644>.

[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>.

[RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, “IP Performance Metrics (IPPM) Standard Advancement Testing”, BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 2012, <https://www.rfc-editor.org/info/rfc6576>.

[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>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[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>.

12.2. Дополнительная литература

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, “Network performance measurement with periodic streams”, RFC 3432, DOI 10.17487/RFC3432, November 2002, <https://www.rfc-editor.org/info/rfc3432>.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications”, STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., “RTP Control Protocol Extended Reports (RTCP XR)”, RFC 3611, DOI 10.17487/RFC3611, November 2003, <https://www.rfc-editor.org/info/rfc3611>.

[RFC4148] Stephan, E., “IP Performance Metrics (IPPM) Metrics Registry”, BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 2005, <https://www.rfc-editor.org/info/rfc4148>.

[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, “A Framework for Packet Selection and Reporting”, RFC 5474, DOI 10.17487/RFC5474, March 2009, <https://www.rfc-editor.org/info/rfc5474>.

[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, “Sampling and Filtering Techniques for IP Packet Selection”, RFC 5475, DOI 10.17487/RFC5475, March 2009, <https://www.rfc-editor.org/info/rfc5475>.

[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, “Information Model for Packet Sampling Exports”, RFC 5477, DOI 10.17487/RFC5477, March 2009, <https://www.rfc-editor.org/info/rfc5477>.

[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, “Session Initiation Protocol Event Package for Voice Quality Reporting”, RFC 6035, DOI 10.17487/RFC6035, November 2010, <https://www.rfc-editor.org/info/rfc6035>.

[RFC6248] Morton, A., “RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete”, RFC 6248, DOI 10.17487/RFC6248, April 2011, <https://www.rfc-editor.org/info/rfc6248>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7012] Claise, B., Ed. and B. Trammell, Ed., “Information Model for IP Flow Information Export (IPFIX)”, RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/info/rfc7012>.

[RFC7014] D’Antonio, S., Zseby, T., Henke, C., and L. Peluso, “Flow Selection Techniques”, RFC 7014, DOI 10.17487/RFC7014, September 2013, <https://www.rfc-editor.org/info/rfc7014>.

[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>.

[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>.

[RFC8912] Morton, A., Bagnulo, M., Eardley, P., and K. D’Souza, “Initial Performance Metrics Registry Entries”, RFC 8912, DOI 10.17487/RFC8912, November 2021, <https://www.rfc-editor.org/info/rfc8912>.

Благодарности

Спасибо Brian Trammell и Bill Cerveny – сопредседателям IPPM во время подготовки документа за проведение «мозговых штурмов» по теме работы. Спасибо Barbara Stark и Juergen Schoenwaelder за подробные отклики и предложения. Спасибо Andrew McGregor за предложения по именованию показателей. Спасибо Michelle Cotton за её раннюю рецензию IANA и Amanda Baber за ответы на вопросы по представлению реестра и доступность полного шаблона по URL. Спасибо Roni Even за его обзор и предложения по обобщению процедур. Спасибо всем руководителям направлений за их рецензии.

Адреса авторов

Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
28911 Leganes Madrid
Spain
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
 
Benoit Claise
Huawei
Email: benoit.claise@huawei.com
 
Philip Eardley
BT
Adastral Park, Martlesham Heath
Ipswich
United Kingdom
Email: philip.eardley@bt.com
 
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
United States of America
Email: acmorton@att.com
 
Aamer Akhter
Consultant
118 Timber Hitch
Cary, NC
United States of America
Email: aakhter@gmail.com
 

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Номер RFC не является первичной эталонной спецификацией для определения метрики (например, [RFC7679] как первичная эталонная спецификация для показателей односторонней задержки). Поле будет содержать метку-заменитель RFCXXXXsecY, пока документу со спецификацией не будет выделен номер RFC, и останется пустым в записях Private Registry без соответствующего RFC. Учитывая «проблему» RFC10K, номер RFC продолжает заменять RFCXXXX, независимо от числа цифр в реальном номере RFC. В ожидании записей от других органов стандартизации форма этого элемента имени должна быть предложена и рецензирована на предмет согласованности и уникальности экспертом-рецензентом.

4Для иных органов стандартизации может потребоваться ссылка на конкретную версию спецификации с датой её выпуска.

Рубрика: RFC | Оставить комментарий

RFC 8912 Initial Performance Metrics Registry Entries

image_print
Internet Engineering Task Force (IETF)                         A. Morton
Request for Comments: 8912                                     AT&T Labs
Category: Standards Track                                     M. Bagnulo
ISSN: 2070-1721                                                     UC3M
                                                              P. Eardley
                                                                      BT
                                                              K. D'Souza
                                                               AT&T Labs
                                                           November 2021

Initial Performance Metrics Registry Entries

Исходные записи реестров показателей производительности

PDF

Аннотация

Этот документ определяет набор начальных записей реестра IANA для показателей производительности (Performance Metrics). Набор включает UDP Round-Trip Latency and Loss, Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss, ICMP Round-Trip Latency and Loss, TCP Round-Trip Delay and Loss.

Статус документа

Документ содержит проект стандарта Internet (Standards Track).

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8912.

Авторские права

Copyright (c) 2021. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML

1. Введение

Этот документ определяет исходный набор записей в реестре метрик производительности (Performance Metrics Registry). Документ использует термины и определения из литературы по параметрам производительности IP (IP Performance Metrics или IPPM), прежде всего [RFC2330].

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

Поэтому в [RFC8911] определён общий формат Performance Metrics Registry и в разделе 5 [RFC8911] даны рекомендации для запросов регистрации метрик, т. е. создания записей в Performance Metrics Registry.

По сути, должно быть доказано, что (1) кандидат на регистрацию метрики представляет отраслевой интерес или уже внедрён и (2) имеется согласие по части того, что метрика-кандидат служит предусмотренной цели.

Процесс, заданный в [RFC8911], требует также администрирования новых записей агентством IANA по процедуре Specification Required [RFC8126], которая обеспечит чёткое определение показателей.

1.1. Уровни требований

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

2. Область действия

Этот документ задаёт исходный набор показателей производительности (Performance Metrics Registry Entriy). Большинство показателей относятся к активным (Active Performance Metrics), которые основаны на RFC, подготовленных рабочей группой IETF IPPM, в соответствии с моделью [RFC2330] и её обновлениями.

3. Категории и столбцы реестра

В этом документе применяются термины, определённые в [RFC8911].

Этот раздел описывает категории и столбцы реестра для упрощения ссылок на них. Запись (строка) даёт полное описание зарегистрированного показателя (Registered Metrics). Формат категорий и столбцов показан ниже.

       Категория
       ------------------...
       Столбец |Столбец |...

   Сводка
   ---------------------------------------------------------------
   Идентификатор| Имя | URI |Описание| Ссылка |Контролёр| Версия |
                |     |     |        |        |изменений|

   Определение показателя
   ----------------------------------------------
   Ссылка на определение|Фиксированные параметры|

   Метод измерения
   ---------------------------------------------------------------------
   Ссылка на | Генерация  | Фильтр  | Распределение| Рабочие    | Роль |
   метод     | потока     | трафика | выборки      | параметры  |      |
             | пакетов    |
   Вывод
   -----------------------------------------
   Тип  | Ссылка на  |Единицы| Калибровка  |
        | определение|       |             |

   Административная информация
   --------------------------------------
   Статус |Запросчик|Выпуск|дата выпуска|

   Комментарии и примечания
   ------------------------


4. Записи для времени кругового обхода и потерь UDP

В этом разделе описаны исходные записи реестра для времени кругового обхода (UDP Round-Trip Latency) и потерь при круговом обходе (UDP Round-Trip Loss Ratio).

Примечание. Каждая запись реестра создаёт лишь необработанный (raw) вывод или статистическую сводку. Для эффективного описания необработанных и статистических результатов категории Identifier, Name, Output могут быть расщеплены, а в одном параграфе могут быть описаны несколько тесно связанных показателей. Например, в этом параграфе заданы две записи реестра, столбцы которых во многом совпадают. Пример задания записей реестра с совпадением многих столбцов приведён в разделе 7.

Записи во всех столбцах кроме ID, Name, Description, Output Reference Method совпадают. Таким образом, этот раздел задаёт две тесно связанных записи в реестре. В результате IANA выделяет соответствующие URL для каждого из двух именованных показателей (Named Metric).

4.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

4.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 1 и 2 для именованных записей раздела 4. Сопоставление идентификаторов с именами приведено в параграфе 4.1.2.

4.1.2. Имя

1: RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile

2: RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio

4.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile

URL: https://www.iana.org/assignments/performance-metrics/RTLoss_Active_IP-UDP-Periodic_RFC8912sec4_Percent_LossRatio

4.1.4. Описание

RTDelay

Показатель оценивает задержку для потока пакетов между двумя хостами (точки измерения). Выводом служит время кругового обхода для всех успешно переданных пакетов в форме 95-го процентиля от условного распределения задержки.

RTLoss

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

4.1.5. Контролёр изменений

IETF

4.1.6. Версия (формата реестра)

1.0

4.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

4.2.1. Ссылки на определения

Задержки

Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681]

В параграфе 2.4 [RFC2681] приведено определение одноэлементного (одно значение) показателя времени кругового обхода (round-trip delay). В параграфе 3.4 [RFC2681] дано расширенное определение с несколькими выборками. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

Отметим, что определение времени кругового обхода между источником (Source или Src) и получателем (Destination или Dst) в параграфе 2.4 [RFC2681] намеренно неоднозначно, этот показатель сужает определение, указывая, что хост в роли Src передаёт первый пакет хосту в роли Dst и в конечном итоге получает соответствующий пакет возврата от Dst (когда ничего не теряется).

Переменная dT в [RFC2681] указывает значение времени кругового обхода в определениях показателя и методах. Это имя переменной также применяется в других документах IPPM для других величин и не может служить в качестве глобального имени переменной.

Потери

Morton, A., “Round-Trip Packet Loss Metrics”, RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>. [RFC6673]

Оба показателя Delay и Loss используют максимальное время ожидания для полученных пакетов, поэтому отношение числа потерянных пакетов к числу переданных является основой для расчёта коэффициента потерь в соответствии с параграфом 6.1 в [RFC6673].

4.2.2. Фиксированные параметры

Определение Type-P приведено в разделе 13 [RFC2330]

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: нет

Заголовок UDP

Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Данные UDP (Payload)

Общий размер 100 байтов.

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

4.3. Метод измерения

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

4.3.1. Ссылки на методы

Методология для этого показателя (эквивалент Type-P-Round-trip-Delay и Type-P-Round-trip-Delay-Poisson-Stream) задана в параграфе 2.6 [RFC2681] (для одиночных измерений) и параграфе 3.6 [RFC2681] (для выборок) с использованием Type-P и Tmax, заданных в столбцах Fixed Parameters. Однако периодический поток будет создаваться в соответствии с [RFC3432].

Эталонный метод отличает пакеты с большой задержкой от потерянных пакетов, задавая максимальное время ожидания прихода пакета. Tmax задаёт время ожидания, служащее порогом для объявления пакета потерянным. Потерянные пакеты нужно обозначать как имеющие неопределённую задержку для показателя RTLoss [RFC6673].

Расчёты задержки (RTT) нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта RTT должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

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

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

В параграфе 4.4 [RFC6673] подробно рассматриваются инструкции по отправке пакетов Type-P обратно в Src как можно быстрее в соответствии с параграфом 2.6 в [RFC2681]. В разделе 8 [RFC6673] указаны дополнительные требования, которые должны быть включены в метод измерения для этого показателя.

4.3.2. Генерация потока пакетов

В этом параграфе приведены детали генерации трафика пакетов, служащего основой для измерений. В показателях IPPM это называется потоком, который легко описывается списком параметров.

В разделе 3 [RFC3432] предписан метод генерации периодических потоков с использованием связанных параметров.

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита) со значением 0,0200, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек).

dT

Продолжительность интервала для разрешённого времени начала выборки со значением 1,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек).
Примечание. Процесс инициирования с множеством управляющих обменов ведёт к непредсказуемому времени старта (в пределах заданного интервала) может предотвратить ненужную синхронизации периодических потоков и послужить заменой выбору времени старта как случайного времени старта из фиксированного интервала.

Параметр T0 будет возвращаться в отчёте как измеренный, параметры incT и dT являются фиксированными.

4.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

4.3.4. Распределение выборки

Неприменимо

4.3.5. Рабочие параметры и формат данных

Рабочие параметры являются входными данными, которые должны быть определены, настроены в системе измерения и включены в отчёт с результатами, чтобы контекст был полным.

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

4.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет.

4.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

4.4.1. Тип

Percentile – персентиль

Для условного распределения всех пакетов с действительным значением времени обхода (неопределённые значения исключаются) это одно значение, соответствующее 95-му процентилю, как указано ниже.
В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. Значение percentile = 95 показывает, что указанная задержка 95Percentile является наименьшим временем кругового обхода (round-trip delay), при котором эмпирическая функция распределения (Empirical Distribution Function) EDF(95Percentile) не меньше 95% одиночных значений round-trip delay в условном распределении. Определение статистики процентилей с использованием EDF дано в параграфе 11.3 [RFC2330].
Для LossRatio отношения числа потерянных пакетов к числу переданных является основой при расчёте коэффициента потерь в соответствии с параграфом 6.1 [RFC6673].

4.4.2. Ссылки на определения

Для всего вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

TotalPkts

Число пакетов, переданных от Src к Dst в интервале измерений.

95Percentile

Время из результата, выраженное в секундах, как положительное число типа decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек).

Percent_LossRatio

Численное значение результата выраженное коэффициентом потери пакетов в процентах в формате decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001.

4.4.3. Единицы измерения

95-й процентиль времени кругового обхода (round-trip delay) в секундах.

Коэффициент потерь при круговом обходе выражается долей потерянных пакетов в процентах.

4.4.4. Калибровка

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

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

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

4.5. Административные элементы

4.5.1. Статус

Действует

4.5.2. Запросчик

RFC 8912

4.5.3. Выпуск

1.0

4.5.4. Дата выпуска

2021-11-17

4.6. Комментарии и заметки

Нет

5. Запись для вариаций задержки пакетов

В этом разделе описана исходная запись реестра для вариаций задержки пакетов (Packet Delay Variation или PDV).

5.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

5.1.1. ID (идентификатор)

Агентство IANA выделило идентификатор 3 для именованных записей раздела 5. Сопоставление идентификаторов с именами приведено в параграфе 5.1.2.

5.1.2. Имя

3: OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile

5.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile

5.1.4. Описание

Этот показатель оценивает вариации относительно минимальной задержки, наблюдаемой в периодическом потоке. Вывод представляется 95-м процентилем распределения задержки пакетов в одном направлении.

5.1.5. Контролёр изменений

IETF

5.1.6. Версия (формата реестра)

1.0

5.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

5.2.1. Ссылки на определения

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>. [RFC2330]

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>. [RFC3393]

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>. [RFC5481]

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>. [RFC5905]

См. параграфы 2.4 и 3.4 в [RFC3393]. Измеренные различия одиночных значений задержки обозначаются переменной ddT (применима ко всем формам вариаций задержки). Однако эта запись задаёт форму PDV, определённую в параграфе 4.2 [RFC5481], где одиночное значение PDV для пакета i обозначается как переменная PDV(i).

5.2.2. Фиксированные параметры

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок UDP

Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Данные UDP (Payload)

Общий размер 200 байтов.

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

F

Функция выбора, однозначно определяющая пакеты из потока для показателя (см. параграф 4.2 в [RFC5481] для формы PDV).

Два дополнительных фиксированных параметра приведены в параграфе «Генерация потока пакетов».

5.3. Метод измерения

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

5.3.1. Ссылки на определения

В параграфах 2.6 и 3.6 of [RFC3393] описаны базовые расчёты для одиночных элементов (singleton). Эта запись реестра требует реализации формы PDV, определённой в параграфе 4.2 [RFC5481]. Измерения рассмотрены также в разделе 8 [RFC5481].

Эталонный метод отличает пакеты с большой задержкой от потерянных пакетов, задавая максимальное время ожидания прихода пакета. Tmax задаёт время ожидания, служащее порогом для объявления пакета потерянным. Потерянные пакеты нужно обозначать как имеющие неопределённую задержку для показателя RTLoss [RFC6673].

Расчёты задержки в одном направлении нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта односторонней задержки должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

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

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

5.3.2. Генерация потока пакетов

В этом параграфе приведены детали генерации трафика пакетов, служащего основой для измерений. В показателях IPPM это называется потоком, который легко описывается списком параметров.

В разделе 3 [RFC3432] предписан метод генерации периодических потоков с использованием связанных параметров.

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита) со значением 0,0200, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек).

dT

Продолжительность интервала для разрешённого времени начала выборки со значением 1,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек).
Примечание. Процесс инициирования с множеством управляющих обменов ведёт к непредсказуемому времени старта (в пределах заданного интервала), может предотвратить ненужную синхронизации периодических потоков и послужить заменой выбору времени старта как случайного значения из фиксированного интервала.

Параметр T0 будет возвращаться в отчёте как измеренный, параметры incT и dT являются фиксированными.

5.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

5.3.4. Распределение выборки

Неприменимо

5.3.5. Рабочие параметры и формат данных

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

5.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет (когда это нужно протоколу тестирования).

5.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

5.4.1. Тип

Percentile – персентиль

Для условного распределения всех пакетов с действительным значением времени обхода (неопределённые значения исключаются) это одно значение, соответствующее 95-му процентилю, как указано ниже.
В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. Значение percentile = 95 показывает, что указанная задержка 95Percentile является наименьшим временем кругового обхода (round-trip delay), при котором эмпирическая функция распределения (Empirical Distribution Function) EDF(95Percentile) не меньше 95% одиночных значений round-trip delay в условном распределении. Определение статистики процентилей с использованием EDF дано в параграфе 11.3 [RFC2330].

5.4.2. Ссылки на определения

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

95Percentile

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

5.4.3. Единицы измерения

95-й персентиль одностороннего значения PDV в секундах.

5.4.4. Калибровка

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

Для измерения задержки в одном направлении калибровка ошибок должна включать оценку синхронизации внутренних часов с внешним источником (внутренние часы задают временные метки для измерений). На практике отклонение часов [RFC5905] источника и получателя нужно считать систематической ошибкой связанной с неточной синхронизацией (отклонение часов сглаживается и случайные вариации обычно не проявляются в результатах).

time_offset

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

При запросе контроллером измерений калибровки применяется внутренняя петля (loopback) и результирующий вывод имеет такой же формат, как при обычном измерении, но включает сведения о факте калибровки. В любых других измерениях измерительной функции следует сообщать текущую оценку смещения часов [RFC5905] как индикатор точности синхронизации.

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

5.5. Административные элементы

5.5.1. Статус

Действует

5.5.2. Запросчик

RFC 8912

5.5.3. Выпуск

1.0

5.5.4. Дата выпуска

2021-11-17

5.6. Комментарии и заметки

Потеря пакетов создаёт проблемы для измерения вариаций задержки. Расширенный анализ и сравнение PDV с межпакетными вариациями задержки (IPDV или Inter-Packet Delay Variation) приведены в параграфе 4.1 [RFC3393] и заявлении о применимости вариаций задержки в [RFC5481].

6. Записи для задержек и потерь для откликов DNS

В этом разделе описаны исходные записи реестра для задержек и потерь откликов DNS на запросы пользователей для именованного ресурса. Показатель может измеряться с повторением для разных именованных ресурсов. Метрика круговой задержки (round-trip delay) определена в [RFC2681] и применяется здесь в качестве основы с указанием нескольких входных параметров для точного определения двух показателей задержки и потерь для откликов DNS.

Все записи столбцов, кроме категорий ID, Name, Description, Output Reference Method одинаковы. Таким образом, этот раздел определяет 2 тесно связанных записи реестра. В результате агентство IANA выделило соответствующие URL для каждой из двух именованных метрик.

6.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

6.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 4 и 5 для именованных записей раздела 6. Сопоставление идентификаторов с именами приведено в параграфе 6.1.2.

6.1.2. Имя

4: RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw

5: RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw

6.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/RTDNS_Active_IP-UDP-Poisson_RFC8912sec6_Seconds_Raw

URL: https://www.iana.org/assignments/performance-metrics/RLDNS_Active_IP-UDP-Poisson_RFC8912sec6_Logical_Raw

6.1.4. Описание

Это метрика производительности откликов DNS для заданного именем ресурса с точки зрения пользователя. Показатель может измеряться неоднократно с использованием разных имён ресурсов.

RTDNS

Этот показатель оценивает время отклика по интервалу между отправкой запроса и получением отклика.

RLDNS

Этот показатель говорит о том, что отклик сочтён потерянным. Иными словами, время отклика превысило максимальное время ожидания.

6.1.5. Контролёр изменений

IETF

6.1.6. Версия (формата реестра)

1.0

6.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

6.2.1. Ссылки на определения

Задержки

Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035> (и обновления). [RFC1035]

Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681]

В параграфе 2.4 [RFC2681] дано определение метрики круговой задержки при одном измерении (singleton). В параграфе 3.4 [RFC2681] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

Для задержки отклика DNS Response объекты [RFC1035] должны сопоставляться с объектами [RFC2681]. Локальный хост с пользовательской программой и распознавателем (Resolver) играют роль источника (Src), а внешний сервер имён (Foreign Name Server) – роль получателя (Dst).

Хотя определение круговой задержки между Src и Dst в T, как указано в параграфе 2.4 [RFC2681], является намеренно неоднозначным в тексте, этот показатель делает определение более строгим, указывая, что хост в роли Src передаёт первый пакет хосту в роли Dst и в конечном итоге получает от того соответствующий пакет возврата Dst (если он не будет потерян).

Потери

Morton, A., “Round-Trip Packet Loss Metrics”, RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>. [RFC6673]

Для потерь откликов DNS объекты [RFC1035] должны сопоставляться с объектами [RFC2681]. Локальный хост с пользовательской программой и распознавателем (Resolver) играют роль источника (Src), а внешний сервер имён (Foreign Name Server) – роль получателя (Dst).

Показатели времени отклика и потерь используют максимальное время ожидания для полученных откликов, поэтому отношение числа потерянных пакетов к числу переданных является основой для расчёта коэффициента потерь в соответствии с параграфом 4.3 в [RFC6673].

6.2.2. Фиксированные параметры

Определение Type-P дано в разделе 13 [RFC2330].

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок UDP

Source port: 53
Destination port: 53
Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Поле данных

Поле данных содержит сообщение DNS, как определено в [RFC1035], с приведёнными ниже значениями.
Раздел заголовка DNS включает:
Identification (см. столбец Runtime)
QR = 0 (запрос)
OPCODE = 0 (стандартный запрос)
AA: не задано
TC: не задано
RD = 1 (желательна рекурсия)
RA: не задано
RCODE: не задано
QDCOUNT = 1 (только одна запись)
ANCOUNT: не задано
NSCOUNT: не задано
ARCOUNT: не задано
Раздел Question содержит:
QNAME: полное доменное имя (Fully Qualified Domain Name или FQDN), указанное при запуске теста (см. столбец Runtime)
QTYPE: тип запроса, указанный при запуске теста (см. столбец Runtime)
QCLASS = 1 (для IN)
Остальные разделы не содержат записей о ресурсах (Resource Record или RR).

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

Observation

Пакеты отклика будут содержать DNS Response и могут включать записи RR.

6.3. Метод измерения

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

6.3.1. Ссылки на определения

Методология для этой метрики (эквивалент Type-P-Round-trip-Delay-Poisson-Stream) определена в параграфе 2.6 [RFC2681] (для одиночных измерений) и параграфе 3.6 [RFC2681] (для выборки) с использованием Type-P и Timeout, указанных в столбце Fixed Parameters.

Эталонный метод отличает пакеты с большой задержкой от потерянных пакетов, задавая максимальное время ожидания прихода пакета. Tmax задаёт время ожидания, служащее порогом для объявления пакета потерянным. Потерянные пакеты нужно обозначать как имеющие неопределённую задержку для показателя RLDNS.

Расчёты задержки (RTT) нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта RTT должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

Эталонный метод требует того или иного способа различать пакеты в потоке для сопоставления времени отправки и получения каждого следующего доставленного пакета.

Сообщения DNS с запросами представляют случайное значение ID Number в поле заголовка Identification, поэтому при использовании ID Number можно вводить новый запрос до завершения обработки предыдущего. Следовательно, значение ID Number должно сохраняться в Src и включаться в каждый пакет отклика для устранения нарушений порядка доставки пакетов, если они возникают.

Если отклик DNS не приходит в интервале Tmax, время RTDNS становится неопределённым, а RLDNS = 1. Нужно использовать идентификаторы сообщений, чтобы различать идентичные последовательные запросы. Поскольку поле ID Number имеет лишь 16 битов, это ограничивает число одновременных запросов DNS при нагрузочных тестах с одного адреса Src.

В параграфе 4.4 [RFC6673] даны подробные инструкции по «возврату пакетов Type-P устройству Src как можно быстрее» в соответствии с параграфом 2.6 в [RFC2681]. Однако от сервера DNS ожидается выполнение всех задач подготовки и отправки отклика, поэтому время отклика будет включать обработку и задержку в сети. В разделе 8 [RFC6673] приведены дополнительные требования, которые нужно включать в метод измерения для этого показателя.

В дополнение к операциям, описанным в [RFC2681], отправитель (Src) должен анализировать заголовки DNS в отклике и готовить данные из отклика для отчёта о результатах измерения вместе с круговой задержкой.

6.3.2. Генерация потока пакетов

В этом параграфе приведены детали генерации трафика пакетов, служащего основой для измерений. В показателях IPPM это называется потоком, который легко описывается списком параметров.

В параграфе 11.1.3 [RFC2330] представлено 3 метода генерации интервалов выборки Пуассона. Обратное lambda значение является средним интервалом между пакетами, т. е. рабочий параметр Reciprocal_lambda = 1/lambda (в секундах).

Использовать нужно метод 3. Если задано время начала (Runtime), время последующих передач рассчитывается до измерения путём вычисления псевдослучайного распределения времени между пакетами (с отсечкой распределения, указанной параметром Trunc) и Src передаёт каждый пакет в расчётное время. Отметим, что Trunc задаёт верхнюю границу интервала между пакетами при распределении Пуассона. Случайные значения больше Trunc уменьшаются до Trunc.

6.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

6.3.4. Распределение выборки

Неприменимо

6.3.5. Рабочие параметры и формат данных

Рабочие (Runtime) параметры служат входными данными, которые должны задаваться и настраиваться в системе управления, а также включаться в результаты для полноты контекста.

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

Reciprocal_lambda

Средний интервал между пакетами в потоке Пуассона, выраженный в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

Trunc

Верхний предел для распределения Пуассона выраженный в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905]. Значения выше этого предела отсекаются до заданного пределом значения.

ID

16-битовый идентификатор, задаваемый программой, которая создаёт запрос. Значение ID должно меняться от запроса к запросу (при необходимости поддерживается список), см. параграф 4.1.1 в [RFC1035]. Этот идентификатор копируется в соответствующий отклик и может применяться запрашивающей стороной (Src) для сопоставления откликов с незавершёнными запросами.

QNAME

Доменное имя для запроса в формате, заданном в разделе 4 [RFC6991].

QTYPE

Тип запроса, соответствующий семейству адреса IP (1 для IPv4, 28 для IPv6) в формате uint16, как указано в параграфе 9.2 [RFC6020].

6.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет.

6.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

6.4.1. Тип

Raw

Для каждого пакета с запросом DNS устанавливаются значения, указанные в следующем столбце (параграф 6.4.2), а значения задержки присваиваются лишь для пакетов, на которые получен отклик.

6.4.2. Ссылки на определения

T

Время отправки запроса DNS в интервале измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

dT

Время задержки получения отклика DNS, выраженное в секундах, как положительное число типа decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек. (1,0 нсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905]. Это значение будет неопределённым, когда Src не получает отклика в интервале Tmax секунд.

RCODE

Значение поля RCODE из заголовка DNS Response в формате uint64, как указано в параграфе 9.2 of [RFC6020]. Ненулевые значения указывают ошибку в отклике и их нужно анализировать отдельно.

Logical

Численное значение из результата, выраженное как логическое – 1 = Lost (потеря), 0 = Received (получено) целым числом типа uint8 (значения от 0 до 255 включительно, см. параграф 9.2 в [RFC6020]). Для запросов с результатом 1 (потеря), в dT и RCODE устанавливаются максимальные значения decimal64 и uint64, соответственно.

6.4.3. Единицы измерения

RTDNS

Круговая задержка dT в секундах.

RLDNS

Логическое значение – 1 = Lost (потеря), 0 = Received (отклик получен).

6.4.4. Калибровка

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

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

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

6.5. Административные элементы

6.5.1. Статус

Действует

6.5.2. Запросчик

RFC 8912

6.5.3. Выпуск

1.0

6.5.4. Дата выпуска

2021-11-17

6.6. Комментарии и заметки

Нет

7. Записи UDP Poisson для односторонней задержки и потерь

В этом разделе описаны исходные записи реестра для UDP Poisson One-Way Delay и UDP Poisson One-Way Loss.

Записи столбцов, кроме ID, Name, Description, Output Reference Method, совпадают, в результате этот раздел задаёт 6 тесно связанных записей реестра, для которых агентство IANA выделило соответствующие URL (для каждого имени).

7.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

7.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 6-11 для именованных записей раздела 7. Сопоставление идентификаторов с именами приведено в параграфе 7.1.2.

7.1.2. Имя

6: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile

7: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Mean

8: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Min

9: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max

10: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_StdDev

11: OWLoss_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Percent_LossRatio

7.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_95Percentile

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Mean

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Min

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_Max

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Seconds_StdDev

URL: https://www.iana.org/assignments/performance-metrics/OWLoss_Active_IP-UDP-Poisson-Payload250B_RFC8912sec7_Percent_LossRatio

7.1.4. Описание

OWDelay

Этот показатель оценивает задержку потока пакетов между двумя хостами (или точками измерения) и сообщает статистическую (<statistic>) одностороннюю задержку для всех успешных обменов пакетами на основе условного распределения задержки. Статистика может иметь форму:
  • 95Percentile
  • Mean
  • Min
  • Max
  • StdDev

OWLoss

Этот показатель оценивает коэффициент потерь для потока пакетов между двумя хостами (точками измерения). Выводом является доля потерь в одном направлении, выраженная отношением числа потерянных пакетов к числу переданных в процентах.

7.1.5. Контролёр изменений

IETF

7.1.6. Версия (формата реестра)

1.0

7.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

7.2.1. Ссылки на определения

Задержки

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>. [RFC7679]

Morton, A. and E. Stephan, “Spatial Composition of Metrics”, RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>. [RFC6049]

В параграфе 3.4 [RFC7679] дано определение метрики односторонней задержки при одном измерении (singleton). В параграфе 4.4 [RFC7679] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

В выборку включаются лишь успешные передачи с конечной задержкой, как указано в параграфе 4.1.2 [RFC6049].

Потери

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>. [RFC7680]

В параграфе 2.4 [RFC7680] дано определение метрики односторонних потерь при одном измерении (singleton). В параграфе 3.4 [RFC7680] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

7.2.2. Фиксированные параметры

Type-P

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок UDP

Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Данные UDP (Payload)

Пакеты в формате TWAMP-Test (параграф 4.1.2 в [RFC5357])
Используемые функции защиты влияют на число октетов заполнения (Padding)
Общий размер составляет 250 октетов, включая тип формата TWAMP, который должен указываться.

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

Два дополнительных фиксированных параметра приведены в параграфе «Генерация потока пакетов».

7.3. Метод измерения

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

7.3.1. Ссылки на определения

Методология для этого показателя (эквивалент Type-P-One-way-Delay-Poisson-Stream) определена в параграфе 3.6 [RFC7679] (для одиночных измерений) и параграфе 4.6 [RFC7679] (для выборок) с использованием Type-P и Tmax, указанных в столбце Fixed Parameters.

Эталонный метод отличает пакеты с большой задержкой от потерянных пакетов, задавая максимальное время ожидания прихода пакета. Tmax задаёт время ожидания, служащее порогом для объявления пакета потерянным. Потерянные пакеты нужно обозначать как имеющие неопределённую задержку для показателя OWLoss

Расчёты задержки в одном направлении нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта односторонней задержки должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

Эталонный метод требует того или иного способа различать пакеты в потоке для сопоставления времени отправки и получения каждого следующего доставленного пакета.

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

7.3.2. Генерация потока пакетов

В этом параграфе приведены детали генерации трафика пакетов, служащего основой для измерений. В показателях IPPM это называется потоком, который легко описывается списком параметров.

В параграфе 11.1.3 [RFC2330] представлено 3 метода генерации интервалов выборки Пуассона. Обратное lambda значение является средним интервалом между пакетами, т. е. рабочий параметр Reciprocal_lambda = 1/lambda (в секундах).

Использовать нужно метод 3. Если задано время начала (Runtime), время последующих передач рассчитывается до измерения путём вычисления псевдослучайного распределения времени между пакетами (с отсечкой распределения, указанной параметром Trunc) и Src передаёт каждый пакет в расчётное время. Отметим, что Trunc задаёт верхнюю границу интервала между пакетами при распределении Пуассона. Случайные значения больше Trunc уменьшаются до Trunc.

Reciprocal_lambda

Средний интервал между пакетами в потоке Пуассона, выраженный в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905]. Reciprocal_lambda = 1 секунда.

Trunc

Верхний предел для распределения Пуассона выраженный в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905]. Значения выше этого предела отсекаются да заданного пределом значения. Trunc = 30,0000 секунд.

7.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

7.3.4. Распределение выборки

Неприменимо

7.3.5. Рабочие параметры и формат данных

Рабочие (Runtime) параметры служат входными данными, которые должны задаваться и настраиваться в системе управления, а также включаться в результаты для полноты контекста.

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

7.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst. Примером является TWAMP Session-Sender.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет. Примером является TWAMP Session-Reflector.

7.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

7.4.1. Тип

Типы рассматриваются ниже.

7.4.2. Ссылки на определения

Для всех типов вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Для LossRatio отношение числа потерянных пакетов к числу переданных служит основой для расчёта коэффициента потерь в соответствии с параграфом 4.1 в [RFC7680].

Для каждого значения <statistic> или Percent_LossRatio применяется один из последующих параграфов.

7.4.2.1. Percentile95

95-й процентиль нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3 [RFC3393] приведены детали расчёта статистики процентилей (круговую задержку следует заменить ipdv).

percentile = 95, означающее, что сообщённая задержка 95Percentile является наименьшей односторонней задержкой, для которой эмпирическая функция распределения (Empirical Distribution Function) или EDF(95Percentile) даёт результат не меньше, чем 95% одиночных значений задержки в условном распределении. Определение статистики с использованием EDF дано в параграфе 11.3 [RFC2330].

95Percentile

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.2. Mean

Среднее значение (mean) нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Mean

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.3. Min

Минимальное значение нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Min

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.4. Max

Максимальное значение нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3.2 [RFC6049] описан тесно связанный метод расчёта этой статистики, а дополнительная информация дана в параграфе 4.3.3 [RFC6049]. Формула расчёта имеет вид

      Max = (FiniteDelay[j])

так что для некоторого значения j (1 <= j <= N) для всех n будет выполняться неравенство

      FiniteDelay[j] >= FiniteDelay[n]

Max

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.5. Std_Dev

Стандартное отклонение (Std_Dev) нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 6.1.4 of [RFC6049] описан тесно связанный метод расчёта этой статистики. Формула представляет собой классический расчёт стандартного отклонения, как показано ниже.

                        _                                       _
                       |            N                            |
                       |           ---                           |
                       |     1     \                          2  |
       Std_Dev = SQRT  |  -------   >   (Delay[n] - MeanDelay)   |
                       |    (N)    /                             |
                       |           ---                           |
                       |          n = 1                          |
                       |_                                       _|

где все пакеты с n от 1 до N имеют значение Delay[n], величина MeanDelay рассчитывается в соответствии с параграфом 7.4.2.2, SQRT[] указывает извлечение квадратного корня.

Std_Dev

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
7.4.2.6. Percent_LossRatio

Percent_LossRatio

Численное значение результата выраженное коэффициентом потери пакетов в процентах в формате decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001.

7.4.3. Единицы измерения

Статистика указывает одностороннюю задержку в секундах, где <statistic> принимает одно из значений:

  • 95Percentile
  • Mean
  • Min
  • Max
  • StdDev

Потери в одном направлении указывается процентным отношениям числа потерянных пакетов к числу переданных.

7.4.4. Калибровка

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

Для измерений задержки в одном направлении калибровка должна включать оценку синхронизации внутренних часов с внешним эталоном (внутренние часы задают измерительные метки). На практике смещение часов [RFC5905] у отправителя и получателя требуется для оценки систематической ошибки в результате неточности часов (смещение часов [RFC5905] сглаживается, поэтому его случайные вариации обычно не влияют на результаты).

time_offset

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

При запросе контроллером измерений калибровки применяется внутренняя петля (loopback) и результирующий вывод имеет такой же формат, как при обычном измерении, но включает сведения о факте калибровки. В любых других измерениях измерительной функции следует сообщать текущую оценку смещения часов [RFC5905] как индикатор точности синхронизации.

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

7.5. Административные элементы

7.5.1. Статус

Действует

7.5.2. Запросчик

RFC 8912

7.5.3. Выпуск

1.0

7.5.4. Дата выпуска

2021-11-17

7.6. Комментарии и заметки

Нет

8. Записи для UDP Periodic One-Way Delay и UDP Periodic One-Way Loss

В этом разделе описаны исходные записи реестра для UDP Periodic One-Way Delay и UDP Periodic One-Way Loss.

Записи столбцов, кроме ID, Name, Description, Output Reference Method, совпадают, в результате этот раздел задаёт 6 тесно связанных записей реестра, для которых агентство IANA выделило соответствующие URL (для каждого имени).

8.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

8.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 12-17 для именованных записей раздела 8. Сопоставление идентификаторов с именами приведено в параграфе 8.1.2.

8.1.2. Имя

12: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_95Percentile

13: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Mean

14: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Min

15: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Max

16: OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_StdDev

17: OWLoss_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Percent_LossRatio

8.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_95Percentile

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Mean

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Min

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_Max

URL: https://www.iana.org/assignments/performance-metrics/OWDelay_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Seconds_StdDev

URL: https://www.iana.org/assignments/performance-metrics/OWLoss_Active_IP-UDP-Periodic20m-Payload142B_RFC8912sec8_Percent_LossRatio

8.1.4. Описание

OWDelay

Этот показатель оценивает задержку потока пакетов между двумя хостами (или точками измерения) и сообщает статистическую (<statistic>) одностороннюю задержку для всех успешных обменов пакетами на основе условного распределения задержки. Статистика может иметь форму:
  • 95Percentile
  • Mean
  • Min
  • Max

OWLoss

Этот показатель оценивает коэффициент потерь пакетов между парой хостов (точки измерения). Результатом служит доля теряемых в одном направлении пакетов, выраженная в процентах.

8.1.5. Контролёр изменений

IETF

8.1.6. Версия (формата реестра)

1.0

8.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

8.2.1. Ссылки на определения

Задержки

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>. [RFC7679]

Morton, A. and E. Stephan, “Spatial Composition of Metrics”, RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>. [RFC6049]

В параграфе 3.4 [RFC7679] дано определение метрики односторонней задержки при одном измерении (singleton). В параграфе 4.4 [RFC7679] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

В выборку включаются лишь успешные передачи с конечной задержкой, как указано в параграфе 4.1.2 [RFC6049].

Потери

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>. [RFC7680]

В параграфе 2.4 [RFC7680] дано определение метрики односторонних потерь при одном измерении (singleton). В параграфе 3.4 [RFC7680] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

8.2.2. Фиксированные параметры

Type-P

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 17 (UDP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 17 (UDP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок UDP

Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.

Данные UDP (Payload)

Пакеты в формате TWAMP-Test (параграф 4.1.2 в [RFC5357])
Используемые функции защиты влияют на число октетов заполнения (Padding)
Общий размер составляет 142 октетов, включая формат TWAMP, который должен указываться при использовании.

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

Три дополнительных фиксированных параметра приведены в параграфе «Генерация потока пакетов».

8.3. Метод измерения

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

8.3.1. Ссылки на определения

Методология для этого показателя (эквивалент Type-P-One-way-Delay-Poisson-Stream) определена в параграфе 3.6 [RFC7679] (для одиночных измерений) и параграфе 4.6 [RFC7679] (для выборок) с использованием Type-P и Tmax, указанных в столбце Fixed Parameters. Однако применяется периодический поток, определённый в [RFC3432].

Эталонный метод отличает пакеты с большой задержкой от потерянных пакетов, задавая максимальное время ожидания прихода пакета. Tmax задаёт время ожидания, служащее порогом для объявления пакета потерянным. Потерянные пакеты нужно обозначать как имеющие неопределённую задержку для показателя OWLoss.

Расчёты задержки в одном направлении нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта односторонней задержки должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

Эталонный метод требует того или иного способа различать пакеты в потоке для сопоставления времени отправки и получения каждого следующего доставленного пакета.

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

8.3.2. Генерация потока пакетов

В этом параграфе приведены детали генерации трафика пакетов, служащего основой для измерений. В показателях IPPM это называется потоком, который легко описывается списком параметров.

В разделе 3 [RFC3432] предписан метод генерации периодических потоков с использованием связанных параметров.

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита) со значением 0,0200, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

dT

Продолжительность интервала для разрешённого времени начала выборки со значением 1,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

T0

Фактическое время запуска периодического потока, определяемое из T0 и dT.
Примечание. Процесс инициирования с множеством управляющих обменов ведёт к непредсказуемому времени старта (в пределах заданного интервала), может предотвратить ненужную синхронизации периодических потоков и послужить заменой выбору времени старта как случайного значения из фиксированного интервала.
Параметр T0 будет возвращаться в отчёте как измеренный, параметры incT и dT являются фиксированными.

Эти параметры потока задаются как рабочие (Runtime).

8.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

8.3.4. Распределение выборки

Неприменимо

8.3.5. Рабочие параметры и формат данных

Рабочие (Runtime) параметры служат входными данными, которые должны задаваться и настраиваться в системе управления, а также включаться в результаты для полноты контекста.

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем лишь 0, время и дата завершения игнорируется, а Tf считается длительностью измерения.

8.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst. Примером является TWAMP Session-Sender.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет. Примером является TWAMP Session-Reflector.

8.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

8.4.1. Тип

Типы задержки и потерь, описанные в последующих параграфах.

8.4.2. Ссылки на определения

Для всех типов вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Для LossRatio отношение числа потерянных пакетов к числу переданных служит основой для расчёта коэффициента потерь в соответствии с параграфом 4.1 в [RFC7680].

Для каждого значения <statistic> или Percent_LossRatio применяется один из последующих параграфов.

8.4.2.1. Percentile95

95-й процентиль нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3 [RFC3393] приведены детали расчёта статистики процентилей (круговую задержку следует заменить ipdv).

percentile = 95, означающее, что сообщённая задержка 95Percentile является наименьшей односторонней задержкой, для которой эмпирическая функция распределения (Empirical Distribution Function или EDF(95Percentile)) дает результат не меньше, чем 95% одиночных значений задержки в условном распределении. Определение статистики с использованием EDF дано в параграфе 11.3 [RFC2330].

95Percentile

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.2. Mean

Среднее значение (mean) нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Mean

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.3. Min

Минимальное значение нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже. В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Min

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.4. Max

Максимальное значение нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3.2 [RFC6049] описан тесно связанный метод расчёта этой статистики, а дополнительная информация дана в параграфе 4.3.3 [RFC6049]. Формула расчёта имеет вид

      Max = (FiniteDelay[j])

так что для некоторого значения j (1 <= j <= N) для всех n будет выполняться неравенство

      FiniteDelay[j] >= FiniteDelay[n]

Max

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.5. Std_Dev

Стандартное отклонение (Std_Dev) нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 6.1.4 of [RFC6049] описан тесно связанный метод расчёта этой статистики. Формула представляет собой классический расчёт стандартного отклонения, как показано ниже.

                        _                                       _
                       |            N                            |
                       |           ---                           |
                       |     1     \                          2  |
       Std_Dev = SQRT  |  -------   >   (Delay[n] - MeanDelay)   |
                       |    (N)    /                             |
                       |           ---                           |
                       |          n = 1                          |
                       |_                                       _|

где все пакеты с n от 1 до N имеют значение Delay[n], величина MeanDelay рассчитывается в соответствии с параграфом 8.4.2.2, SQRT[] указывает извлечение квадратного корня.

Std_Dev

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
8.4.2.6. Percent_LossRatio

Percent_LossRatio

Численное значение результата выраженное коэффициентом потери пакетов в процентах в формате decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001.

8.4.3. Единицы измерения

Статистика указывает одностороннюю задержку в секундах, где <statistic> принимает одно из значений:

  • 95Percentile
  • Mean
  • Min
  • Max
  • StdDev

Потери в одном направлении указывается процентным отношениям числа потерянных пакетов к числу переданных.

8.4.4. Калибровка

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

Для измерений задержки в одном направлении калибровка должна включать оценку синхронизации внутренних часов с внешним эталоном (внутренние часы задают измерительные метки). На практике смещение часов [RFC5905] у отправителя и получателя требуется для оценки систематической ошибки в результате неточности часов (смещение часов [RFC5905] сглаживается, поэтому его случайные вариации обычно не влияют на результаты).

time_offset

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

При запросе контроллером измерений калибровки применяется внутренняя петля (loopback) и результирующий вывод имеет такой же формат, как при обычном измерении, но включает сведения о факте калибровки. В любых других измерениях измерительной функции следует сообщать текущую оценку смещения часов [RFC5905] как индикатор точности синхронизации.

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

8.5. Административные элементы

8.5.1. Статус

Действует

8.5.2. Запросчик

RFC 8912

8.5.3. Выпуск

1.0

8.5.4. Дата выпуска

2021-11-17

8.6. Комментарии и заметки

Нет

9. Записи для ICMP Round-Trip Latency и ICMP Round-Trip Loss

В этом разделе описаны исходные записи реестра для ICMP Round-Trip Latency и ICMP Round-Trip Loss Ratio.

Записи столбцов, кроме ID, Name, Description, Output Reference Method, совпадают, в результате этот раздел задаёт 4 тесно связанные записей реестра, для которых агентство IANA выделило соответствующие URL (для каждого имени).

9.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

9.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 18-21 для именованных записей раздела 9. Сопоставление идентификаторов с именами приведено в параграфе 9.1.2.

9.1.2. Имя

18: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean

19: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min

20: RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max

21: RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio

9.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Mean

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Min

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Seconds_Max

URL: https://www.iana.org/assignments/performance-metrics/RTLoss_Active_IP-ICMP-SendOnRcv_RFC8912sec9_Percent_LossRatio

9.1.4. Описание

RTDelay

Этот показатель оценивает задержку потока пакетов ICMP, передаваемых между парой хостов (точки измерения). Выводом служит круговая задержка для всех пакетов с успешным обменом, выраженная как статистика условного распределения, где статистикой может быть :
  • Mean
  • Min
  • Max

RTLoss

Этот показатель оценивает коэффициент потери пакетов, передаваемых между двумя хостами (точки измерения). Выводом является доля теряемых в обоих направлениях (round-trip) пакетов, выраженная в процентах.

9.1.5. Контролёр изменений

IETF

9.1.6. Версия (формата реестра)

1.0

9.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

9.2.1. Ссылки на определения

Задержки

Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681]

В параграфе 2.4 [RFC2681] дано определение метрики круговой задержки при одном измерении (singleton). В параграфе 3.4 [RFC2681] приведено расширенное определение для множественных выборок. Термины «одноэлементный» (singleton) и выборка (sample) определены в разделе 11 [RFC2330].

Хотя определение круговой задержки между Src и Dst в параграфе 2.4 [RFC2681] является намеренно неоднозначным в тексте, этот показатель делает определение более строгим, указывая, что хост в роли Src передаёт первый пакет хосту в роли Dst и в конечном итоге получает от того соответствующий пакет возврата Dst (если он не будет потерян).

Переменная dT в [RFC2681] указывает значение времени кругового обхода в определениях показателя и методах. Это имя переменной также применяется в других документах IPPM для других величин и не может служить в качестве глобального имени переменной.

Потери

Morton, A., “Round-Trip Packet Loss Metrics”, RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>. [RFC6673]

Показатели времени отклика и потерь используют максимальное время ожидания для полученных откликов, поэтому отношение числа потерянных пакетов к числу переданных является основой для расчёта коэффициента потерь в соответствии с параграфом 6.1 в [RFC6673].

9.2.2. Фиксированные параметры

Определение Type-P дано в разделе 13 [RFC2330].

Заголовок IPv4

DSCP = 0
TTL = 255
Protocol = 01 (ICMP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 128 (десятичное, ICMP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок ICMP

Type: 8 (Echo Request)
Code: 0
Checksum: контрольная сумма должна рассчитываться и отличное от 0 значение включается в заголовок.
(Идентификатор и порядковый номер, устанавливаемые при работе)

ICMP Payload:

32 байта случайных данных, не меняющиеся в течение теста

Другие параметры измерения

Tmax

Время ожидания порога потерь со значением 3,0, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек. (0,1 мсек). Используется преобразование без потерь между этим параметром и 32-битовыми временными метками NTP в соответствии с разделом 6 в [RFC5905].

9.3. Метод измерения

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

9.3.1. Ссылки на определения

Методология для этой метрики (эквивалент Type-P-Round-trip-Delay-Poisson-Stream) определена в параграфе 2.6 [RFC2681] (для одиночных измерений) и параграфе 3.6 [RFC2681] (для выборки) с использованием Type-P и Timeout, указанных в столбце Fixed Parameters.

Эталонный метод отличает пакеты с большой задержкой от потерянных пакетов, задавая максимальное время ожидания прихода пакета. Tmax задаёт время ожидания, служащее порогом для объявления пакета потерянным. Потерянные пакеты нужно обозначать как имеющие неопределённую задержку для показателя RTLoss.

Расчёты задержки RTD нужно выполнять для условного распределения при успешном получении пакета в интервале Tmax. Кроме того, когда все задержки пакетов записаны (сохранены), процесс расчёта RTD должен обеспечить соответствие порогу Tmax для сохранённых значений до выполнения расчётов. В параграфе 4.1 [RFC3393] подробно описано условное распределение для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] даны базовые сведения об этом анализе.

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

Измерительный процесс будет определять порядковые номера для тестовых пакетов после передачи этому процессу фиксированных и рабочих параметров. Протокол измерения ICMP будет задавать формат номеров или иных идентификаторов.

В параграфе 4.4 [RFC6673] даны подробные инструкции по «возврату пакетов Type-P устройству Src как можно быстрее» в соответствии с параграфом 2.6 в [RFC2681]. Однако от сервера DNS ожидается выполнение всех задач подготовки и отправки отклика, поэтому время отклика будет включать обработку и задержку в сети. В разделе 8 [RFC6673] приведены дополнительные требования, которые нужно включать в метод измерения для этого показателя.

9.3.2. Генерация потока пакетов

В этом параграфе приведены детали генерации трафика пакетов, служащего основой для измерений. В показателях IPPM это называется потоком, который легко описывается списком параметров.

Показатели ICMP используют дисциплину передачи SendOnRcv (Send On Receive) – передача в ответ на получение. Это является модификацией требований раздела 3 в [RFC3432], задающего метод генерации периодических потоков с использованием связанных параметров, как указано ниже.

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита).

dT

Длительность интервала разрешённого времени начала выборки.

Параметр потока incT задаётся как рабочий (Runtime), а dT не применяется в SendOnRcv.

Отправитель SendOnRcv ведёт себя так же, как генератор периодического потока, пока все пакеты откликов приходят с RTD < incT, а межпакетный интервал является постоянным. Если пакеты отклика приходят с RTD >= incT, межпакетный интервал для времени следующей передачи номинально составляет RTD. Если пакет отклика не приходит в интервале Tmax, межпакетный интервал для времени следующей передачи номинально составляет Tmax.

Для незамедлительной отправки при получении отклика (Send On Reply) устанавливается incT = 0.

9.3.3. Детали фильтрации (наблюдения) трафика

Неприменимо

9.3.4. Распределение выборки

Неприменимо

9.3.5. Рабочие параметры и формат данных

Рабочие (Runtime) параметры служат входными данными, которые должны задаваться и настраиваться в системе управления, а также включаться в результаты для полноты контекста.

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

incT

Номинальная продолжительность межпакетного интервала (от первого бита до первого бита) со значением 0,0200, выраженным в секундах, как положительное число типа decimal64 с 4 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,0001 сек (0,1 мсек).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Count

Общее число переданных пакетов ICMP Echo Request в формате uint16, как указано в параграфе 9.2 [RFC6020].

Дополнительные рабочие параметры описаны в параграфе «Генерация потока пакетов».

9.3.6. Роли

Src

Отправляет каждый пакет и ждёт возврата от Dst.

Dst

Ждёт каждого пакета от Src и передаёт тому возвратный пакет ((ICMP Echo Reply, типа 0).

9.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

9.4.1. Тип

Типы для задержки и потерь описаны в последующих параграфах.

9.4.2. Ссылки на определения

Для всех типов вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

TotalCount

Число пакетов, переданных фактически от Src к Dst в течение интервала измерения.

Для каждого значения <statistic> или Percent_LossRatio применяется один из последующих параграфов.

9.4.2.1. Mean

Среднее значение (mean) нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Mean

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
9.4.2.2. Min

Минимальное значение нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Min

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
9.4.2.3. Max

Максимальное значение нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3.2 [RFC6049] описан тесно связанный метод расчёта этой статистики, а дополнительная информация дана в параграфе 4.3.3 [RFC6049]. Формула расчёта имеет вид

      Max = (FiniteDelay[j])

так что для некоторого значения j (1 <= j <= N) для всех n будет выполняться неравенство

      FiniteDelay[j] >= FiniteDelay[n]

Max

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
9.4.2.4. Percent_LossRatio

Для LossRatio отношение числа потерянных пакетов к общему числу переданных пакетов служит основой при расчёте коэффициента потерь в соответствии с параграфом 4.1 в [RFC7680].

Percent_LossRatio

Численное значение результата выраженное коэффициентом потери пакетов в процентах в формате decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001.

9.4.3. Единицы измерения

Статистика указывает одностороннюю задержку в секундах, где <statistic> принимает одно из значений:

  • Mean
  • Min
  • Max

Потери в обоих направлениях указываются процентным отношениям числа потерянных пакетов к числу переданных.

9.4.4. Калибровка

В параграфе 3.7.3 [RFC7679] представлены способы количественной оценки систематических и случайных ошибок при измерениях. Калибровку на месте можно включить с помощью внутренней петли (loopback) на хосте источника, что позволяет использовать различные измерительные системы, выполнять манипуляции с адресами при необходимости и обеспечивать ту или иную изоляцию (например, детерминированную задержку) от влияния интерфейсов передачи и приёма. Таким способом можно получить характеристики части случайных и систематических ошибок.

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

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

9.5. Административные элементы

9.5.1. Статус

Действует

9.5.2. Запросчик

RFC 8912

9.5.3. Выпуск

1.0

9.5.4. Дата выпуска

2021-11-17

9.6. Комментарии и заметки

Нет

10. Записи для TCP Round-Trip Delay и TCP Round-Trip Loss

В этом разделе описаны исходные записи реестра для пассивной оценки круговой задержки TCP (TCP Round-Trip Delay или RTD) и круговых потерь TCP (TCP Round-Trip Loss Count).

Записи столбцов, кроме ID, Name, Description, Output Reference Method, совпадают, в результате этот раздел задаёт 4 тесно связанные записей реестра, для которых агентство IANA выделило соответствующие URL (для каждого имени).

10.1. Сводка

Эта категория включает индексы записей реестра – идентификатор элемента (ID) и имя показателя (Metric Name).

10.1.1. ID (идентификатор)

Агентство IANA выделило идентификаторы 22-26 для именованных записей раздела 10. Сопоставление идентификаторов с именами приведено в параграфе 10.1.2.

10.1.2. Имя

22: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean

23: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min

24: RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max

25: RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton4

26: RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count

10.1.3. URI

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Mean

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Min

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Passive_IP-TCP_RFC8912sec10_Seconds_Max

URL: https://www.iana.org/assignments/performance-metrics/RTDelay_Passive_IP-TCP-HS_RFC8912sec10_Seconds_Singleton

URL: https://www.iana.org/assignments/performance-metrics/RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count

10.1.4. Описание

RTDelay

Этот показатель оценивает круговую (round-trip) задержку пакетов TCP в одном соединении между парой хостов. Измерение такой задержки происходит в одной точке наблюдения (Observation Point или OP) [RFC7011] где-либо в сети. Результатом является круговая задержка для успешного обмена пакетами, выраженная как статистика условного распределения задержки, которая может принимать вид:
  • Mean
  • Min
  • Max

RTDelay Singleton

Этот показатель оценивает круговую задержку пакетов TCP, инициирующих 1 соединение (3-way handshake) между парой хостов. Рассматривается измерение круговой задержки в одной точке наблюдения (OP) [RFC7011] где-либо в сети. Выводом является одно значение Round-trip delay (Singleton).

RTLoss

Этот параметр оценивает число потерь пакетов TCP в одном соединении между парой хостов. Рассматривается число потерь5, обнаруженное в одной OP [RFC7011] где-либо в сети. Выводом является оценка числа потерь в интервале измерений.

10.1.5. Контролёр изменений

IETF

10.1.6. Версия (формата реестра)

1.0

10.2. Определение показателя

Эта категория включает столбцы для ввода всех необходимых деталей, включая ссылки на RFC и значения входных параметров, называемых фиксированными (Fixed).

10.2.1. Ссылки на определения

Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>. [RFC2681]

RFC с описанием пассивного измерения круговой задержки нет, а определение для активного измерения дано в [RFC2681].

В этом определении метрики применяется термин «время в линии» (wire time), как определено в параграфе 10.2 [RFC2330], а также термины «одиночный» (singleton) и «выборка» (sample), определённые в разделе 11 [RFC2330]. В параграфе 2.4 [RFC2681] приведено эталонное определение singleton-метрики круговой задержки (одно значение), а в параграфе [RFC2681] – это определение расширено для выборки нескольких значений.

Поскольку OP [RFC7011] обычно находится между участвующими в соединении TCP хостами, показатель круговой задержки требует 2 отдельных измерений между OP и каждым из хостов, чтобы объединение этих результатов (Spatial Composition) [RFC6049] давало одно значение round-trip delay (композиция двух значений односторонней задержки в круговую задержку субпути).

С учётом направления передачи TCP SYN для привязки хост A передаёт SYN, а хост B отвечает пакетом SYN-ACK в процессе организации соединения. Направление передачи SYN считается прямым (Forward) от A через OP хосту B (обратным будет направление от B через OP к хосту A).

Фильтры трафика сокращают поток пакетов на OP до нужного (Qualified) уровня двухсторонней передачи.

В приведённых ниже определениях соответствующие фильтру пакеты (Corresponding Packet) передаются в разных направлениях и имеют общее поле в заголовке TCP, которое определяет соответствие (насколько это возможно). Примером может служит поле временных меток TCP.

Для действительного числа RTD_fwd (круговая задержка в прямом направлении от OP к B в момент T’) требуется, чтобы в точке OP наблюдался Qualified Packet к хосту B в момент T’, хост B принял этот пакет и передал соответствующий пакет обратно хосту A, а точка наблюдения OP увидела этот пакет в момент (wire time) T’ + RTD_fwd.

Для действительного числа RTD_rev (круговая задержка в обратном направлении от OP к A в момент T”) требуется, чтобы точка OP наблюдала Qualified Packet к хосту A в момент T”, хост A получил этот пакет и передал соответствующий отклик хосту B, а точка наблюдения OP увидела этот пакет в момент T” + RTD_rev.

В идеале пакету от B к A в обоих приведённых выше определениях следует быть одним и тем же (при измерении сначала RTD_rev это относится к пакету от A к B).

Требуемая функция объединения (Composition Function) для одиночного измерения круговой задержки в момент T (более ранний среди указанных выше T’ и T”) имеет вид

   RTDelay = RTD_fwd + RTD_rev

Отметим, что при размещении OP на хосте A или B один из элементов RTDelay становится нулевым или пренебрежимо малым.

При обозначении согласования TCP применяется сокращение HS. Когда пакеты Qualified и Corresponding являются TCP-SYN и TCP-SYN-ACK, RTD_fwd == RTD_HS_fwd. Когда пакеты Qualified и Corresponding являются TCP-SYN-ACK и TCP-ACK, RTD_rev == RTD_HS_rev.

Требуемая функция объединения для одиночного (singleton) измерения круговой задержки при согласовании имеет вид

   RTDelay_HS = RTD_HS_fwd + RTD_HS_rev

В определении счётчика потерь в обоих направлениях используются описанные выше правила, основанные на наблюдении порядковых номеров TCP и сохранении наблюдаемых пропусков (gap). Потерю можно определить из указанных ниже событий.

Сегменты с нарушением порядка

Сегменты TCP передаются с монотонно возрастающими порядковыми номерами, но сегменты могут быть приняты с нарушением порядка. В разделе 3 [RFC4737] описывается понятие «следующего ожидаемого номера» (next expected), которое можно приспособить к сегментам TCP (для обнаружения нарушенного порядка). Наблюдение нарушающих порядок пакетов указывает потерю на пути до OP и пропуск в номерах.

Дубликаты сегментов

В разделе 2 [RFC5560] определены идентичные пакеты и это подходит для оценки пакетов TCP при обнаружении дубликатов. Дубликат ранее наблюдавшегося сегмента (и отсутствие соответствующего пропуска в наблюдаемых номерах) говорит о потере пакета на пути после OP (например, сегмент перекрывается с частью потока октетов, уже отмеченного в OP).

Каждый случай нарушения порядка или дублирования сегментов подразумевает одиночную (singleton) потерю, но подсчёт круговых потерь выполняется для интервала измерения, который в этом случае совпадает с одним соединением TCP.

В приведённых выше наблюдениях для прямого направления число сегментов с нарушением порядка и дубликатов определяется как RTL_fwd. Соответствующие наблюдения в направлении Reverse определяются как RTL_rev.

Для интервала измерения (одно соединение TCP) от T0 до Tf требуемая функция объединения двух счётчиков подразумеваемых потерь для каждого направления имеет вид

   RTLoss = RTL_fwd + RTL_rev

10.2.2. Фиксированные параметры

Фильтры трафика

Заголовок IPv4

DSCP = 0
Protocol = 06 (TCP)

Заголовок IPv6

DSCP = 0
Hop Count = 255
Next Header = 6 (TCP)
Flow Label = 0
Заголовки расширения: Нет

Заголовок TCP

Флаги: ACK, SYN, FIN, установленные должным образом

Timestamps Option (Tsopt)

Указана, см. параграф 3.2 в [RFC7323]

10.3. Метод измерения

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

10.3.1. Ссылки на определения

Базовая методология для этой метрики определена в разделе 4 [RFC7323] на основе опции Timestamp с изменениями, разрешающими приложения на OP в в пути [RFC7011]. Дополнительные детали и применимая эвристика выведены из работ [Strowes] и [Trammell-14].

Фильтр трафика на OP настраивается для наблюдения одного соединения TCP. В процессе согласования SYN/SYN-ACK/ACK это предоставляет первую возможность измерить RTD_fwd (по паре SYN – SYN-ACK) и RTD_rev (по паре SYN-ACK – ACK). Обозначим это одиночное измерение RTDelay как RTDelay_HS (общая задержка для направления Forward и Reverse). RTDelay_HS нужно обрабатывать отдельно от значений RTDelay для пакетов данных и их ACK. Значение RTDelay_HS можно использовать для проверки согласованности композитных значений RTDelay для пакетов данных.

Для пакетов с данными OP измеряет интервал времени между наблюдением пакета с порядковым номером s и отклика ACK с тем же номером. При передаче данных от хоста A к хосту B это будет интервал RTD_fwd.

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

Поскольку передача данных во многих случаях является односторонней (например, в направлении Forward от A к B), для измерения RTD_rev необходимо использовать «чистые» пакеты ACK с временной меткой (TSval) и пакеты с «отражённой» временной меткой. Временной интервал между наблюдением ACK от B к A и соответствующим пакетом с полем Timestamp Echo Reply (TSecr) [RFC7323] определяет значение RTD_rev.

Эвристика фильтрации измерений задержки описана ниже.

  • Если данные (payload) передавались в обоих направлениях Forward и Reverse, может применяться правило измерения времени кругового обхода (Round-Trip Time Measurement) из параграфа 4.1 в [RFC7323]. Это правило по сути исключает какие-либо измерения, если пакет «не продвигается в передаче» (сдвиг левого края окна передачи в соответствии с [Strowes]).

  • Эвристика [Trammell-14] исключает RTD_rev со значениями больше наблюдавшихся ранее. Это ведёт к исключению измерений в обратном (Reverse) направлении, выполненных при отсутствии у приложения данных для передачи, поскольку в этом случае к RTD_rev может быть добавлено значительное время.

  • Отметим, что в приведённой выше эвристике предполагается, что хост A передаёт данные. Если этот хост является принимающим, эвристику следует применять к RTD_fwd.

  • Статистические расчёты задержки (RTDelay) нужно выполнять для условного распределения при условии успешных измерений в направлениях Forward и Reverse в соответствии с эвристикой.

Метод фиксации (Inferring) потерь указан ниже.

  • OP отслеживает порядковые номера и сохраняет пропуски для каждого направления передачи, а также следующий ожидаемый порядковый номер, как указано в [Trammell-14] и [RFC4737]. Потеря фиксируется по нарушению порядка или дублированию сегментов.

Эвристика фильтрации измерения потерь.

  • В [Trammell-14] добавлено окно оценки на основе RTDelay.

  • Следует отличать пакеты с нарушением порядка от сегментов с порядком, нарушенным в результате потери, поскольку пропуск в порядковых номерах заполняется в том же окне RTDelay. Обнаружение сегментов с нарушенным порядком в соответствии с [RFC4737] должно вести к снижению счётчика потерь выведенных на основе неупорядоченных сегментов.

  • Число ложных (ненужных) повторов передачи (наблюдаемых как дубликаты) также может быть снижено этим способом, как описано в [Trammell-14].

Источники ошибок.

  • Основным источником ошибок RTDelay является время обработки хостом для возврата пакета, который определяет завершение интервала измерения. Приведённая выше эвристика предназначена для смягчения этих ошибок за счёт исключения измерений, где время обработки хостом составляет значительную часть RTD_fwd или RTD_rev.

  • Основным источником ошибок RTLoss является потеря наблюдения, как описано в разделе 3 [Trammell-14].

10.3.2. Генерация потока пакетов

Неприменимо

10.3.3. Детали фильтрации (наблюдения) трафика

Указанные выше фиксированные параметры задают часть фильтров трафика. Другие аспекты задают рабочие (Runtime) параметры, описанные ниже.

10.3.4. Распределение выборки

Эта метрика требует полной выборки всех пакетов, соответствующих критериям Traffic Filter.

10.3.5. Рабочие параметры и формат данных

Рабочие (Runtime) параметры служат входными данными, которые должны задаваться и настраиваться в системе управления, а также включаться в результаты для полноты контекста.

Src

IP-адрес хоста в роли источника (Src Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

Dst

IP-адрес хоста в роли получателя (Dst Role) в формате ipv4-address-no-zone для IPv4 и ipv6-address-no-zone для IPv6 (см. раздел 4 в [RFC6991]).

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. При T0, содержащем только 0, время старта не задано и Tf интерпретируется как интервал измерений, а время старта контролируется иными средствами.

Tf

Необязательное время завершения интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]) или длительность интервала измерения. Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. Кроме того, завершение интервала измерения может контролироваться измеряемым соединением, когда вторая пара пакетов (FIN и ACK) между хостами A и B фактически завершает интервал.

TTL или Hop Limit

Устанавливается желаемое значение.

10.3.6. Роли

Хост A

Запускает пакет SYN для организации соединения. Роль host A является синонимом адреса IP на хосте A.

Хост B

Отвечает пакетом SYN-ACK для организации соединения. Роль host B является синонимом адреса IP на хосте B.

10.4. Вывод

Эта категория задаёт все детали вывода измерений с использованием показателя.

10.4.1. Тип

Типы RTDelay рассматриваются ниже.

RTLoss – число потерянных пакетов.

10.4.2. Ссылки на определения

Для всех типов вывода

T0

Время начала интервала измерений (в формате date-time, заданном в параграфе 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC.

Tf

Конец интервала измерений (в формате date-time из параграфа 5.6 [RFC3339], см. также date-and-time в разделе 3 [RFC6991]). Параграф 6.1 в [RFC2330] требует использовать часовой пояс UTC. Конец интервала измерения может контролироваться измеряемым соединением, когда вторая пара пакетов (FIN и ACK) между хостами A и B фактически завершает интервал.

RTDelay_Passive_IP-TCP-HS

Круговая задержка при согласовании является одиночным результатом (Singleton).

RTLoss

Число потерянных пакетов.

Для статистики, Singleton и Loss Count применим один из описанных ниже вариантов.

10.4.2.1. Mean

Среднее значение (mean) нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Mean

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
10.4.2.2. Min

Минимальное значение нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.2.2 [RFC6049] приведены детали расчёта статистики, а дополнительная информация дана в параграфе 4.2.3 [RFC6049].

Min

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
10.4.2.3. Max

Максимальное значение нужно рассчитывать с использованием условного распределения всех пакетов с конечным значением односторонней задержки (неопределённые задержки исключаются) – одно значение, как указано ниже.

В параграфе 4.1 [RFC3393] подробно описано получение условного распределения для исключения неопределённых значений задержки, а в разделе 5 [RFC6703] обоснован этот выбор анализа. В параграфе 4.3.2 [RFC6049] описан тесно связанный метод расчёта этой статистики, а дополнительная информация дана в параграфе 4.3.3 [RFC6049]. Формула расчёта имеет вид

      Max = (FiniteDelay[j])

так что для некоторого значения j (1 <= j <= N) для всех n будет выполняться неравенство

      FiniteDelay[j] >= FiniteDelay[n]

Max

Время из результата, выраженное в секундах положительным числом decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].
10.4.2.4. Singleton

Одиночный результат (singleton) нужно рассчитывать с использованием RTD_fwd (для пары SYN и SYN-ACK) и RTD_rev (для пары SYN-ACK и ACK), как указано в параграфе 10.3.1.

Значение singleton – это время из результата, выраженное в секундах положительным числом типа decimal64 с 9 цифрами в дробной части (см. параграф 9.3 в [RFC6020]) с дискретностью 0,000000001 сек (1,0 нсек). Выполняется преобразование без потерь между этим значением и 64-битовыми временными метками NTP в соответствии с разделом 6 [RFC5905].

10.4.2.5. Счётчики потерь

RTLoss_Passive_IP-TCP_RFC8912sec10_Packet_Count

Число потерянных пакетов.

Наблюдение сегментов с нарушениям порядка или дублированием ведёт к фиксации потери после применения определений из параграфа 10.2.1 и эвристики для измерения потерь из параграфа 10.3.1. Определение круговых потерь выполняется в интервале измерения, которым является одно соединение TCP.

Для интервала измерения (одно соединение TCP) от T0 до Tf требуемая функция объединения двух счётчиков подразумеваемых потерь для каждого направления имеет вид

   RTLoss = RTL_fwd + RTL_rev

Packet count

Числовое значение результат выраженное количеством потерянных пакетов в форме целого числа типа uint64 (значение от 0 до 18446744073709551615 включительно, см. параграф 9.2 в [RFC6020]).

10.4.3. Единицы измерения

Статистика указывает одностороннюю задержку в секундах, где <statistic> принимает одно из значений:

  • Mean
  • Min
  • Max

Одиночное измерение круговой задержки трехэтапного согласования TCP выражается в секундах.

Потери при круговом обходе выражаются числом потерянных пакетов.

10.4.4. Калибровка

Пассивные измерения в точке OP могут быть откалиброваны по активным измерениям (с эмуляцией потерь) на хосте A или B, где активное измерение определяет точность.

10.5. Административные элементы

10.5.1. Статус

Действует

10.5.2. Запросчик

RFC 8912

10.5.3. Выпуск

1.0

10.5.4. Дата выпуска

2021-11-17

10.6. Комментарии и заметки

Нет

11. Вопросы безопасности

Записи реестра не оказывают известных влияний на безопасность Internet. За исключением [RFC1035], все упомянутые здесь RFC содержат раздел «Вопросы безопасности». Кроме того, модель LMAP [RFC7594] обеспечивает при измерениях безопасность и приватность (конфиденциальность).

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

12. Взаимодействие с IANA

Агентство IANA заполнило реестр Performance Metrics, определённый в [RFC8911] значениями, указанными в разделах 4 – 10.

Дополнительная информация приведена в разделе «Взаимодействие с IANA» [RFC8911].

13. Литература

13.1. Нормативные документы

[RFC1035] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[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>.

[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>.

[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.

[RFC3339] Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps”, RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[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>.

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, “Network performance measurement with periodic streams”, RFC 3432, DOI 10.17487/RFC3432, November 2002, <https://www.rfc-editor.org/info/rfc3432>.

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, “Packet Reordering Metrics”, RFC 4737, DOI 10.17487/RFC4737, November 2006, <https://www.rfc-editor.org/info/rfc4737>.

[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>.

[RFC5560] Uijterwaal, H., “A One-Way Packet Duplication Metric”, RFC 5560, DOI 10.17487/RFC5560, May 2009, <https://www.rfc-editor.org/info/rfc5560>.

[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>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6049] Morton, A. and E. Stephan, “Spatial Composition of Metrics”, RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>.

[RFC6673] Morton, A., “Round-Trip Packet Loss Metrics”, RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information”, STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., “TCP Extensions for High Performance”, RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

[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>.

[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, “Registry for Performance Metrics”, RFC 8911, DOI 10.17487/RFC8911, November 2021, <https://www.rfc-editor.org/info/rfc8911>.

[Strowes] Strowes, S., “Passively Measuring TCP Round-Trip Times”, Communications of the ACM, Vol. 56 No. 10, Pages 57-64, DOI 10.1145/2507771.2507781, October 2013, <https://dl.acm.org/doi/10.1145/2507771.2507781>.

[Trammell-14] Trammell, B., Gugelmann, D., and N. Brownlee, “Inline Data Integrity Signals for Passive Measurement”, In: Dainotti A., Mahanti A., Uhlig S. (eds) Traffic Monitoring and Analysis. TMA 2014. Lecture Notes in Computer Science, vol 8406. Springer, Berlin, Heidelberg, DOI 10.1007/978-3-642-54999-1_2, March 2014, <https://link.springer.com/chapter/10.1007/978-3-642-54999-1_2>.

13.2. Дополнительная литература

[RFC1242] Bradner, S., “Benchmarking Terminology for Network Interconnection Devices”, RFC 1242, DOI 10.17487/RFC1242, July 1991, <https://www.rfc-editor.org/info/rfc1242>.

[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>.

[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>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

Благодарности

Авторы благодарят Brian Trammell за предложенный термин Runtime Parameters, который позволил отделить рабочие параметры от фиксированных, например, для идентификации метрики экспорта данных потока IP IP (Flow Information Export или IPFIX) с помощью Flow Key, предложения метрики Passive TCP RTD Metric, ссылки для поддержки и множество иных конструктивных предложений. Спасибо Peter Koch за несколько полезных предложений по устранению неоднозначности последовательных запросов DNS для метрики откликов DNS Response.

Авторы также признательны Barbara Stark, Juergen Schoenwaelder, Tim Carey, Yaakov Stein и участникам рабочей группы LMAP за конструктивный обзор и полезные предложения. Спасибо Michelle Cotton за её ранние обзоры в IANA и Amanda Baber за ответы на вопросы, связанные с представлением реестра и доступностью полного шаблона по URL.

Адреса авторов

Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
United States of America
Phone: +1 732 420 1571
Email: acmorton@att.com
 
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
28911 Leganes Madrid
Spain
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
 
Philip Eardley
BT
Adastral Park, Martlesham Heath
Ipswich
United Kingdom
Email: philip.eardley@bt.com
 
Kevin D’Souza
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
United States of America
Phone: +1 732 420 2514
Email: kld@att.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3См. [RFC7679] с примером традиционного шаблона IPPM, в значительной степени основанного на шаблоне рабочей группы Benchmarking Methodology из [RFC1242], и похожий шаблон в [RFC6390].

4Отметим, что наблюдатель в промежуточной точке может получить лишь 1 значение RTDelay для согласования TCP.

5В оригинале ошибочно указана круговая задержка. См. https://www.rfc-editor.org/errata/eid6762. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 8913 Two-Way Active Measurement Protocol (TWAMP) YANG Data Model

image_print
Internet Engineering Task Force (IETF)                          R. Civil
Request for Comments: 8913                             Ciena Corporation
Category: Standards Track                                      A. Morton
ISSN: 2070-1721                                                AT&T Labs
                                                               R. Rahman
                                                                        
                                                         M. Jethanandani
                                                     Xoriant Corporation
                                                     K. Pentikousis, Ed.
                                                                 Detecon
                                                           November 2021

Two-Way Active Measurement Protocol (TWAMP) YANG Data Model

Модель данных YANG для протокола TWAMP

PDF

Аннотация

Этот документ задаёт модель данных для реализации клиентов и серверов протокола двухсторонних активных измерений (Two-Way Active Measurement Protocol или TWAMP). Документ определяет модель данных TWAMP с помощью диаграмм классов унифицированного языка моделирования (Unified Modeling Language или UML) и формально определяет её с использованием языка моделирования данных YANG (RFC 7950). Модель данных совместима с архитектурой хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA).

Статус документа

Документ содержит проект стандарта Internet (Standards Track).

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8913.

Авторские права

Copyright (c) 2021. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML.

1. Введение

Протокол TWAMP [RFC5357] служит для измерения параметров производительности сети, таких как задержка, пропускная способность и потеря пакетов, путём передачи пробных пакетов и измерения параметров их передачи через сеть. На сегодняшний день реализации TWAMP не поставляются со стандартной системой управления, поэтому разработчикам остаётся лишь предоставлять свой механизм. Документ решает этот вопрос, определяя модель с использованием диаграмм классов UML [UML] и формально задаёт модель данных TWAMP, совместимую с архитектурой NMDA) [RFC8342], используя язык YANG 1.1 [RFC7950].

1.1. Мотивация

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

Есть две основные тенденции стандартизации управления TWAMP. Во-первых, предполагается, что в ближайшие годы крупномасштабное развёртывание TWAMP от разных производителей станет нормой. С точки зрения эксплуатации использование нескольких механизмов настройки TWAMP, зависящих от производителя, является дорогим и неэффективным по сравнению с применением одного стандартного механизма. Во-вторых, рост числа программно-управляемых и виртуализованных сетевых систем, основанных на динамических цепочках служб [NSC] с программируемыми плоскостями управления [RFC7426], требует чётко определённой модели данных для реализации TWAMP. Этот документ определяет такую модель данных TWAMP и задаёт её формально с использованием языка моделирования данных YANG 1.1 [RFC7950].

1.2. Уровни требований

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

1.3. Организация документа

В разделе 2 описана область действия и применимость документа, раздел 3 содержит высокоуровневый обзор модели данных TWAMP. В разделе 4 описаны параметры конфигурации модели данных, а раздел 5 задаёт модель данных YANG для TWAMP. В разделе 6 приведены примеры, соответствующие описанной модели данных YANG, приложение A содержит подробное описание этих примеров.

2. Область действия, модель и применимость

Целью этого документа является спецификация независимой от производителя модели данных для реализаций TWAMP.

На рисунке 1 приведена логическая модель TWAMP, заимствованная из параграфа 1.2 спецификации TWAMP [RFC5357], с указателями на диаграммы UML [UML], приведённые в этом документе и связанные с моделями данных 4 логических элементов системы TWAMP – Control-Client, Server, Session-Sender, Session-Reflector. Руководство по обозначениям UML (Notation Guide) приведено в разделе 5 [UML].

В соответствии с TWAMP [RFC5357] непомеченные соединения на рисунке 1 не задаются и могут быть фирменными протоколами.

   (Рисунок 3)                             (Рисунок 4)
+----------------+                          +--------+
| Control-Client |  <-- TWAMP-Control -->   | Server |
+----------------+                          +--------+
        ^                                        ^
        |                                        |
        V                                        V
+----------------+                     +-------------------+
| Session-Sender |  <-- TWAMP-Test --> | Session-Reflector |
+----------------+                     +-------------------+
   (Рисунок 5)                              (Рисунок 6)

Рисунок 1. Логическая модель TWAMP.

Согласно TWAMP [RFC5357], реализация TWAMP может следовать упрощённой логической модели, в которой один узел может выступать в качестве Control-Client и Session-Sender, а другой быть сервером TWAMP и Session-Reflector. На рисунке 2 показана упрощённая логическая модель и взаимодействия между клиентом конфигурации и сервером TWAMP, например в NETCONF [RFC6241] или RESTCONF [RFC8040].

o-------------------o                       o-------------------o
|Клиент конфигурации|                       |Клиент конфигурации|
o-------------------o                       o-------------------o
         ||                                          ||
 NETCONF || RESTCONF                         NETCONF || RESTCONF
         ||                                          ||
o-------------------o                       o-------------------o
|Сервер конфигурации|                       |Сервер конфигурации|
|  (Рисунки 3 и 5)  |                       |  (Рисунки 4 и 6)  |
+-------------------+                       +-------------------+
|   Control-Client  | <-- TWAMP-Control --> |      Server       |
|                   |                       |                   |
|   Session-Sender  |  <-- TWAMP-Test -->   | Session-Reflector |
+-------------------+                       +-------------------+

Рисунок 2. Упрощённая модель TWAMP и протоколы.

Определённая в этом документе модель ортогональна протоколу, используемому между клиентом и сервером конфигурации для передачи параметров настройки TWAMP.

Операционные действия, такие как запуск и остановка сессий TWAMP-Test, извлечение результатов теста и т. п., не рассматриваются в описанной здесь модели конфигурации. Как отмечено выше, такие действия не являются частью спецификации TWAMP [RFC5357] и поэтому выходят за рамки документа (см. Приложение B). Кроме того, для рабочего состояния может применяться информация из реестра метрик производительности (Performance Metrics Registry) [RFC8911] [PERF-METRICS], позволяющая создать независимую модель для параметров производительности, которые нужно собрать и извлечь.

3. Обзор модели данных

Модель данных TWAMP включает 4 категории элементов конфигурации.

  1. Элементы глобальной конфигурации задаются на уровне устройства. Например, это может быть административный статус сеансов TWAMP, а в случае их разрешения – возможности сессии (например, Control-Client, сервер или оба сразу).

  2. Атрибуты, задаваемые на уровне соединения TWAMP-Control, такие как IP-адрес сервера.

  3. Атрибуты сессии TWAMP-Test, например, различные значения поля DSCP (Differentiated Services Code Point).

  4. Атрибуты рабочего состояния реализации TWAMP.

Поскольку модель данных TWAMP описана в последующих разделах документа, читателю следует помнить о группировке функциональных элементов, показанной на рисунке 1.

3.1. Control-Client

TWAMP Control-Client имеет поле административного статуса, установленное на уровне устройства, которое показывает, включена ли функция на устройстве. Каждый TWAMP Control-Client может быть связан с одним или несколькими соединениями TWAMP-Control. Основные параметры управляющих соединений указаны ниже.

  • Имя, которое может служить для однозначного указания конкретного управляющего соединения на Control-Client. Имя требуется для программируемости, поскольку в момент организации соединения TWAMP-Control доступна не вся информация об адресе IP и номере порта TCP, требуемая для однозначного указания соединения.

  • Адрес IP на интерфейсе, который Control-Client будет использовать для соединений.

  • IP-адрес удалённого сервера TWAMP.

  • Атрибуты проверки подлинности и шифрования, такие как KeyID, Token и вектор инициализации Control-Client (Client-IV), описанные в параграфе 3.1 документа «A One-way Active Measurement Protocol (OWAMP)» [RFC4656] и документе «Randomness Requirements for Security» [RFC4086].

Каждое соединение TWAMP-Control может быть связано с одной или несколькими сессиями TWAMP-Test. Для каждого сеанса тестирования следует указывать перечисленные ниже параметры конфигурации.

  • Имя тестовой сессии, которое однозначно указывает конкретный сеанс на уровне Control-Client и Session-Sender. Подобно указанным выше управляющим соединениям это уникальное имя сеанса нужно по причине того, что на момент создания сессии TWAMP-Test такие параметры, как номер порта UDP ещё не известны.

  • Адрес IP и номер порта UDP в Session-Sender на пути, тестируемом с помощью TWAMP.

  • Адрес IP и номер порта UDP в Session-Reflector на пути, тестируемом с помощью TWAMP.

  • Сведения, относящиеся к потоку тестовых пакетов, такие как время запуска теста, применяемая метрика производительности (Performance Metric) в соответствии с «Registry for Performance Metrics» [RFC8911], повторяемость теста.

3.2. Сервер

Каждый сервер TWAMP имеет поле административного статуса, устанавливаемое на уровне устройства, для управления возможностью включения функции TWAMP Server.

Каждый сервер может иметь одно или несколько соединений TWAMP-Control, каждое из который однозначно указывается квартетом {IP-адрес Control-Client, номер порта TCP у Control-Client, IP-адрес сервера, номер порта TCP на сервере}. Элементы конфигурации управляющего соединения TWAMP Server доступны лишь для чтения.

3.3. Session-Sender

TWAMP Session-Sender имеет поле административного статуса, устанавливаемое на уровне устройства, для управления возможностью включения функции.

Для каждой сессии TWAMP-Test имеется один экземпляр Session-Sender, инициируемый передающим устройством. Основные поля конфигурации указаны ниже.

  • Имя тестовой сессии, которое должно совпадать с именем соответствующего сеанса тестирования на TWAMP Control-Client (параграф 3.1).

  • Имя управляющего соединения, которое вместе с именем сеанса тестирования однозначно указывает экземпляр TWAMP Session-Sender.

  • Сведения, относящиеся к потоку тестовых пакетов, такие как число пакетов и их распределение (см. «Network performance measurement with periodic streams» [RFC3432]).

3.4. Session-Reflector

TWAMP Session-Reflector имеет поле административного статуса, устанавливаемое на уровне устройства, для управления возможностью включения функции.

С каждым Session-Reflector может быть связана одна или несколько сессий TWAMP-Test, для каждой из которых можно настроить тайм-аут REFWAIT, управляющий прерыванием сессии при отсутствии принимаемых пакетов (параграф 4.2 в TWAMP [RFC5357]).

Предусмотрен доступ для чтения других параметров модели данных, таких как IP-адрес отправителя. Каждая тестовая сессия однозначно указывается квартетом, указанным в параграфе 3.2.

4. Параметры модели данных

В этом разделе определена модель данных TWAMP с использованием UML [UML] и вводятся отдельные параметры, связанные с 4 логическими элементами TWAMP. Полная спецификация модели данных TWAMP в форме модуля YANG представлена в параграфе 5.2.

4.1. Control-Client

Контейнер клиента (рисунок 3) содержит элементы, относящиеся к логическому элементу TWAMP Control-Client (рисунок 1). Этот контейнер включает административный параметр конфигурации (client/admin-state), управляющий возможностью инициировать соединения TWAMP-Control.

+-------------+
| client      |
+-------------+                   1..* +-----------------------+
| admin-state |<>----------------------| mode-preference-chain |
|             |                        +-----------------------+
|             |  1..* +------------+   | priority              |
|             |<>-----| key-chain  |   | mode                  |
+-------------+       +------------+   +-----------------------+
       ^              | key-id     |
       V              | secret-key |
       |              +------------+
       | 0..*
+------------------------+
| ctrl-connection        |
+------------------------+
| name                   |
| client-ip              |
| server-ip              |
| server-tcp-port        |    0..* +----------------------+
| control-packet-dscp    |<>-------| test-session-request |
| key-id                 |         +----------------------+
| max-count              |         | name                 |
| client-tcp-port   {ro} |         | sender-ip            |
| server-start-time {ro} |         | sender-udp-port      |
| state             {ro} |         | reflector-ip         |
| selected-mode     {ro} |         | reflector-udp-port   |
| token             {ro} |         | timeout              |
| client-iv         {ro} |         | padding-length       |
+------------------------+         | test-packet-dscp     |
                                   | start-time           |
            +-------------+ 1      | repeat               |
            | pm-reg-list |------<>| repeat-interval      |
            +-------------+        | state           {ro} |
            | pm-index    |        | sid             {ro} |
            +-------------+        +----------------------+

Рисунок 3. Диаграмма классов UML для TWAMP Control-Client.

Контейнер client содержит список (mode-preference-chain), задающий режим значений в соответствии с предпочтительным порядком их использования оператором этого Control-Client, включая режимы проверки подлинности и шифрования. В частности, списки mode-preference-chain содержат режим и соответствующий приоритет в форме 16-битовых целых чисел без знака. Значения приоритета начинаются с 0 (высший) и увеличиваются на 1.

Среди режимов, доступных в Server Greeting, Control-Client должен выбрать из списка mode-preference-chain режим с наивысшим приоритетом. В списке предпочтительных режимов может одновременно устанавливаться несколько битовых позиций, например, при обращении к расширенным функциям TWAMP в «Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)» [RFC5618], «Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)» [RFC5938], «Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features» [RFC6038], «IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)» [RFC7717]. Если Control-Client не может определить подходящий режим или комбинация битов не имеет смысла (например, установлены биты authenticated и unauthenticated), он должен ответить Set-Up-Response со сброшенными битами Mode, указывающим нежелание продолжать управляющее соединение.

Кроме того в контейнере client содержится список key-chain, связывающий key-id с соответствующим секретным ключом. Сервер и Control-Client используют одно отображение key-id на secret-key (на рисунке 3) и для того, чтобы это работало корректно, значение key-id должно быть уникальным среди всех систем в административном домене. Сервер, подготовленный для сеансов с разными Control-Client, использует key-id для выбора подходящего секретного ключа, а Control-Client обычно использует свой секретный ключ для каждого сервера. Ключ secret-key является общим секретом типа binary и ему следует иметь не менее 128 битов энтропии. Представлению key-id и secret-key следует соответствовать параграфу 9.8 в YANG [RFC7950]. Размер производного ключа (dkLen в «PKCS #5: Password-Based Cryptography Specification Version 2.1» [RFC8018]) должен быть не меньше 16 октетов для AES Session-key при шифровании и 32 октетов для HMAC-SHA1 Session-key при проверке подлинности (см. также параграф 6.10 в OWAMP [RFC4656]).

В каждом контейнере client также содержится список управляющих соединений, каждый элемент которого описывает соединение TWAMP-Control, инициируемое этим Control-Client. Нужно указать одно управляющее соединение (ctrl-connection) на соединение TWAMP-Control (TCP), инициируемое с данного устройства.

В каждом ctrl-connection содержится список test-session-request с информацией, связанной с Control-Client для этого сеанса тестирования. Включаются сведения, связанные с обменом сообщениями Request-TW-Session и Accept-Session (см. параграф 3.5 в TWAMP [RFC5357]).

Нужно указать один экземпляр test-session-request для каждой сессии TWAMP-Test, которая должна согласовываться этим соединением TWAMP-Control через обмен сообщениями Request-TW-Session, Accept-Session.

Control-Client также отвечает за планирование сеансов TWAMP-Test, поэтому в test-session-request содержатся сведения об этих действиях (например, pm-index, repeat-interval).

4.2. Сервер

Контейнер server (рисунок 4) содержит элементы, относящиеся к конфигурации логического объекта TWAMP Server (рисунок 1). Контейнер включает административный параметр конфигурации (server/admin-state), управляющий возможностью восприятия устройством соединений TWAMP-Control.

Устройство, работающее в роли сервера (Server Role) не может задавать атрибуты на уровне соединений TWAMP-Control, поскольку оно не знает заранее о входящих соединениях TWAMP-Control. Поэтому все параметры, которые сервер может захотеть применять для входящих соединений, должны настраиваться на уровне сервера и применяются ко всем входящим соединениям TWAMP-Control.

+---------------------+
| server              |
+---------------------+
| admin-state         |   1..* +------------+
| server-tcp-port     |<>------| key-chain  |
| servwait            |        +------------+
| control-packet-dscp |        | key-id     |
| count               |        | secret-key |
| max-count           |        +------------+
| modes               |
|                     |   0..* +--------------------------+
|                     |<>------| ctrl-connection          |
+---------------------+        +--------------------------+
                               | client-ip           {ro} |
                               | client-tcp-port     {ro} |
                               | server-ip           {ro} |
                               | server-tcp-port     {ro} |
                               | state               {ro} |
                               | control-packet-dscp {ro} |
                               | selected-mode       {ro} |
                               | key-id              {ro} |
                               | count               {ro} |
                               | max-count           {ro} |
                               | salt                {ro} |
                               | server-iv           {ro} |
                               | challenge           {ro} |
                               +--------------------------+

Рисунок 4. Диаграмма классов UML для сервера TWAMP.

Каждый контейнер server содержит список key-chain, связывающий key-id с соответствующим secret-key. Как отмечено в параграфе 4.1, Server и Control-Client используют одно сопоставление key-id с общим ключом secret-key и для корректной работы значение key-id должно быть уникальным для каждой системы в административном домене. Сервер, подготовленный к работе с несколькими Control-Client, использует key-id для выбора подходящего secret-key, а Control-Client обычно используют отдельный секретный ключ для каждого сервера. Значение key-id указывает серверу, какой из ключей secret-key клиент Control-Client желает применять для проверки подлинности и шифрования.

Каждое активное входящее управляющее соединение на сервере представляется объектом ctrl-connection. Нужно указать один объект ctrl-connection на каждое входящее соединение TWAMP-Control (TCP), которое воспринято и активно на сервере. Каждый объект ctrl-connection может быть однозначно указан квартетом {client-ip, client-tcp-port, server-ip, server-tcp-port}. Все элементы списка ctrl-connection доступны лишь для чтения.

4.3. Session-Sender

Контейнер session-sender, показанный на рисунке 5, содержит элементы, относящиеся к логическому объекту TWAMP Session-Sender. В session-sender помещается административный параметр (session-sender/admin-state) управляющий возможностью устройства инициировать сессии TWAMP-Test.

+----------------+
| session-sender |
+----------------+  0..* +---------------------------+
| admin-state    |<>-----| test-session              |
+----------------+       +---------------------------+
                         | name                      |
                         | ctrl-connection-name {ro} |
                         | fill-mode                 |
                         | number-of-packets         |
                         | state                {ro} |
                         | sent-packets         {ro} |
                         | rcv-packets          {ro} |
                         | last-sent-seq        {ro} |
                         | last-rcv-seq         {ro} |
                         +---------------------------+
                                      ^
                                      V
                                      | 1
                          +---------------------+
                          | packet-distribution |
                          +---------------------+
                          | periodic / poisson  |
                          +---------------------+
                              |           |
                   +-------------------+  |
                   | periodic-interval |  |
                   +-------------------+  |
                                          |
                                   +--------------+
                                   | lambda       |
                                   | max-interval |
                                   +--------------+

Рисунок 5. Диаграмма классов UML для Session-Sender.

Каждая сессия TWAMP-Test, созданная Session-Sender, будет представляться объектом test-session. Нужно создавать 1 объект test-session для каждой сессии TWAMP-Test, в которой будут передаваться пакеты.

4.4. Session-Reflector

Контейнер session-reflector, показанный на рисунке 6, содержит элементы, относящиеся к конфигурации логического объекта TWAMP Session-Reflector. В session-reflector включается административный параметр (session-reflector/admin-state), управляющий возможностью устройства воспринимать входящие сессии TWAMP-Test.

+-------------------+
| session-reflector |
+-------------------+
| admin-state       |
| refwait           |
+-------------------+
         ^
         V
         |
         | 0..*
+----------------------------------------+
| test-session                           |
+----------------------------------------+
| sid                               {ro} |
| sender-ip                         {ro} |
| sender-udp-port                   {ro} |
| reflector-ip                      {ro} |
| reflector-udp-port                {ro} |
| parent-connection-client-ip       {ro} |
| parent-connection-client-tcp-port {ro} |
| parent-connection-server-ip       {ro} |
| parent-connection-server-tcp-port {ro} |
| test-packet-dscp                  {ro} |
| sent-packets                      {ro} |
| rcv-packets                       {ro} |
| last-sent-seq                     {ro} |
| last-rcv-seq                      {ro} |
+----------------------------------------+

Рисунок 6. Диаграмма классов UML для Session-Reflector.

Устройство в роли Session-Reflector не может настраивать атрибуты на уровне сессии, поскольку заранее не знает о входящих сеансах. Поэтому все параметры, которые Session-Reflector может пожелать применить к входящим сессиям TWAMP-Test, должны настраиваться на уровне Session-Reflector и будут применяться ко всем входящим сессиям. Каждую входящую сессию TWAMP-Test, активную в Session-Reflector, нужно представлять 1 экземпляром объекта test-session. Все элементы test-session доступны лишь для чтения.

Экземпляры test-session индексируются идентификатором сессии (Session Identifier или SID) в параметре sid. Значения SID автоматически выделяет TWAMP Server по мере получения запросов на сеансы тестирования и возвращается их клиентам Control-Client в поле SID сообщения Accept-Session, как указано в параграфе 4.3 «Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features» [RFC6038].

При попытке получить рабочие данные для сеансов тестирования от устройства Session-Reflector пользователь не знает, какие сессии в данный момент активны на устройстве и какие SID выделены для них. Если у пользователя есть сетевой доступ к устройству Control-Client, он может прочитать данные для сессии из client/ctrl-connection/test-session-request/sid и получить значение SID (рисунок 3). Это значение SID можно использовать в качестве индекса для получения отдельного экземпляра session-reflector/test-session с устройства Session-Reflector. Если у пользователя нет доступа к Control-Client через сеть, единственным способом является извлечение всех экземпляров test-session с устройства Session-Reflector и поиск среди них нужного пользователю. Это может быть проблематично при большом числе активных сессий на устройстве.

Каждая сессия TWAMP-Test на устройстве Session-Reflector включает квартет {parent-connection-client-ip, parent-connection-client-tcp-port, parent-connection-server-ip, parent-connection-server-tcp-port}, который должен соответствовать эквивалентному квартету {client-ip, client-tcp-port, server-ip, server-tcp-port} в server/ctrl-connection. Этот квартет позволяет пользователю отслеживать сессию TWAMP-Test до (родительского) соединения TWAMP-Control, согласовавшего сеанс тестирования.

5. Модель данных

В этом разделе приведена формальная спецификация модели данных TWAMP с использованием YANG.

5.1. Диаграмма дерева YANG

В этом параграфе дано упрощённое графическое представление модели данных TWAMP с использованием дерева YANG. Читателям следует помнить, что ограничение размера строки 72 символами ведёт к искусственному переводу строк в некоторых узлах дерева. В этом документе используются диаграммы с нотацией, заданной в «YANG Tree Diagrams» [RFC8340].

Следует отметить, что символ \ в конце строки применяется в этом документе для разделения длинных строк на несколько (например, [reflector-udp-port] в диаграмме дерева является частью [sender-ip sender-udp-port reflector-ip]).

   module: ietf-twamp
     +--rw twamp
        +--rw client {control-client}?
        |  +--rw admin-state?             boolean
        |  +--rw mode-preference-chain* [priority]
        |  |  +--rw priority    uint16
        |  |  +--rw mode?       twamp-modes
        |  +--rw key-chain* [key-id]
        |  |  +--rw key-id        string
        |  |  +--rw secret-key?   binary
        |  +--rw ctrl-connection* [name]
        |     +--rw name                    string
        |     +--rw client-ip?              inet:ip-address
        |     +--rw server-ip               inet:ip-address
        |     +--rw server-tcp-port?        inet:port-number
        |     +--rw control-packet-dscp?    inet:dscp
        |     +--rw key-id?                 string
        |     +--rw max-count-exponent?     uint8
        |     +--ro client-tcp-port?        inet:port-number
        |     +--ro server-start-time?      uint64
        |     +--ro repeat-count?           uint64
        |     +--ro state?
        |     |       control-client-connection-state
        |     +--ro selected-mode?          twamp-modes
        |     +--ro token?                  binary
        |     +--ro client-iv?              binary
        |     +--rw test-session-request* [name]
        |        +--rw name                  string
        |        +--rw sender-ip?            inet:ip-address
        |        +--rw sender-udp-port?      union
        |        +--rw reflector-ip          inet:ip-address
        |        +--rw reflector-udp-port?   inet:port-number
        |        +--rw timeout?              uint64
        |        +--rw padding-length?       uint32
        |        +--rw test-packet-dscp?     inet:dscp
        |        +--rw start-time?           uint64
        |        +--rw repeat?               uint32
        |        +--rw repeat-interval?      uint32
        |        +--rw pm-reg-list* [pm-index]
        |        |  +--rw pm-index    uint16
        |        +--ro state?                test-session-state
        |        +--ro sid?                  string
        +--rw server {server}?
        |  +--rw admin-state?           boolean
        |  +--rw server-tcp-port?       inet:port-number
        |  +--rw servwait?              uint32
        |  +--rw control-packet-dscp?   inet:dscp
        |  +--rw count?                 uint8
        |  +--rw max-count-exponent?    uint8
        |  +--rw modes?                 twamp-modes
        |  +--rw key-chain* [key-id]
        |  |  +--rw key-id        string
        |  |  +--rw secret-key?   binary
        |  +--ro ctrl-connection*
        |          [client-ip client-tcp-port server-ip server-tcp-port]
        |     +--ro client-ip              inet:ip-address
        |     +--ro client-tcp-port        inet:port-number
        |     +--ro server-ip              inet:ip-address
        |     +--ro server-tcp-port        inet:port-number
        |     +--ro state?                 server-ctrl-connection-state
        |     +--ro control-packet-dscp?   inet:dscp
        |     +--ro selected-mode?         twamp-modes
        |     +--ro key-id?                string
        |     +--ro count?                 uint8
        |     +--ro max-count-exponent?    uint8
        |     +--ro salt?                  binary
        |     +--ro server-iv?             binary
        |     +--ro challenge?             binary
        +--rw session-sender {session-sender}?
        |  +--rw admin-state?    boolean
        |  +--rw test-session* [name]
        |     +--rw name                    string
        |     +--ro ctrl-connection-name?   string
        |     +--rw fill-mode?              padding-fill-mode
        |     +--rw number-of-packets       uint32
        |     +--rw (packet-distribution)?
        |     |  +--:(periodic)
        |     |  |  +--rw periodic-interval       decimal64
        |     |  +--:(poisson)
        |     |     +--rw lambda                  decimal64
        |     |     +--rw max-interval?           decimal64
        |     +--ro state?                  sender-session-state
        |     +--ro sent-packets?           uint32
        |     +--ro rcv-packets?            uint32
        |     +--ro last-sent-seq?          uint32
        |     +--ro last-rcv-seq?           uint32
        +--rw session-reflector {session-reflector}?
           +--rw admin-state?    boolean
           +--rw refwait?        uint32
           +--ro test-session*
                   [sender-ip sender-udp-port reflector-ip \
                    reflector-udp-port]
              +--ro sid?                                string
              +--ro sender-ip                           inet:ip-address
              +--ro sender-udp-port
              |       dynamic-port-number
              +--ro reflector-ip                        inet:ip-address
              +--ro reflector-udp-port                  inet:port-number
              +--ro parent-connection-client-ip?        inet:ip-address
              +--ro parent-connection-client-tcp-port?  inet:port-number
              +--ro parent-connection-server-ip?        inet:ip-address
              +--ro parent-connection-server-tcp-port?  inet:port-number
              +--ro test-packet-dscp?                   inet:dscp
              +--ro sent-packets?                       uint32
              +--ro rcv-packets?                        uint32
              +--ro last-sent-seq?                      uint32
              +--ro last-rcv-seq?                       uint32

Рисунок 7. Диаграмма дерева YANG.

5.2. Модуль YANG

В этом параграфе представлен модуль YANG для модели данных TWAMP, заданной этим документом. Модуль импортирует определения из «Common YANG Data Types» [RFC6991] и ссылается на документы «Framework for IP Performance Metrics» [RFC2330], «Network performance measurement with periodic streams» [RFC3432], «A One-way Active Measurement Protocol (OWAMP)»” [RFC4656], «A Two-Way Active Measurement Protocol (TWAMP)» [RFC5357], «Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)» [RFC5618], «Network Time Protocol Version 4: Protocol and Algorithms Specification» [RFC5905], «Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)» [RFC5938], «Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features» [RFC6038], «Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)» [RFC7312], «IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)» [RFC7717], «Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)» [RFC8545], «Registry for Performance Metrics» [RFC8911].

   <CODE BEGINS> file "ietf-twamp@2021-11-17.yang"
   module ietf-twamp {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-twamp";
     prefix ietf-twamp;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }

     organization
       "IETF IPPM (IP Performance Metrics) Working Group";
     contact
       "WG Web: <https://datatracker.ietf.org/wg/ippm/documents/>
        WG List: <mailto:ippm@ietf.org>

        Editor: Ruth Civil
                <mailto:ruthcivil@gmail.com>

        Editor: Al Morton
                <mailto:acmorton@att.com>

        Editor: Reshad Rahman
                <mailto:reshad@yahoo.com>

        Editor: Mahesh Jethanandani
                <mailto:mjethanandani@gmail.com>

        Editor: Kostas Pentikousis
                <mailto:kostas.pentikousis@detecon.com>";
     description
       "Этот модуль YANG задаёт независимую от производителя модель
        данных для протокола TWAMP (Two-Way Active Measurement Protocol).

        Модель определяет 4 логических элемента TWAMP - Control-Client, 
        Server, Session-Sender, Session-Reflector, как показано в
        логической модели TWAMP (рисунок 1 в RFC 8913).

        Модуль YANG использует функции (feature) для индикации логических 
        элементов, поддерживаемых реализацией TWAMP.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

        Авторские права (Copyright (c) 2021) принадлежат IETF Trust и
        лицам, указанным как авторы. Все права защищены.

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 8913, где правовые
        аспекты приведены более полно.";
     revision 2021-11-17 {
       description
         "Исходный выпуск.

          Ссылается на RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717,
          RFC 8911.";
       reference
         "RFC 8913: Two-Way Active Measurement Protocol (TWAMP) YANG
          Data Model";
     }

     /*
      * Определения типов
      */

     typedef twamp-modes {
       type bits {
         bit unauthenticated {
           position 0;
           description
             "Режим без аутентификации, где не применяется проверка
              подлинности и шифрование в TWAMP-Control и TWAMP-Test.
              KeyID, Token, Client-IV не применяются в сообщениях
              Set-Up-Response. См. параграф 3.1 в RFC 4656.";
           reference
             "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
                        параграф 3.1";
         }
         bit authenticated {
           position 1;
           description
             "режим с аутентификацией, в котором Control-Client и
              Server владеют общим секретом, не позволяющим 'кражу 
              услуг'. В соответствии с разделом 6 RFC 4656, в режиме
              с аутентификацией 'временные метки передаются открыто
              без криптографической защиты, а остальная часть сообщения
              имеет такую же защиту как в режиме с шифрованием. Этот
              режим обеспечивает компромисс между защитой и точностью.'";
           reference
             "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
                        раздел 6";
         }
         bit encrypted {
           position 2;
           description
             "режим с шифрованием 'делает невозможным незаметное изменение
              временных меток' (раздел 1 в RFC 4656). См. также раздел 4
              в RFC 7717.";
           reference
             "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
                        раздел 6
              RFC 7717: IKEv2-Derived Shared Secret Key for the One-Way
              Active Measurement Protocol (OWAMP) and Two-Way Active
              Measurement Protocol (TWAMP), раздел 4";
         }
         bit unauth-test-encrypt-control {
           position 3;
           description
             "При использовании смешанного режима защиты протокол TWAMP-Test
              работает в режиме без аутентификации, а TWAMP-Control — в
              режиме с шифрованием.";
           reference
             "RFC 5618: Mixed Security Mode for the Two-Way Active
              Measurement Protocol (TWAMP)";
         }
         bit individual-session-control {
           position 4;
           description
             "Этот режим разрешает отдельные тестовые сессии, использующие
              Session Identifier.";
           reference
             "RFC 5938: Individual Session Control Feature
              for the Two-Way Active Measurement Protocol (TWAMP)";
         }
         bit reflect-octets {
           position 5;
           description
             "Этот режим указывает свойство отражения пакетов.";
           reference
             "RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
              Reflect Octets and Symmetrical Size Features";
         }
         bit symmetrical-size {
           position 6;
           description
             "Этот режим указывает поддержку симметричного размера
              тестовых пакетов отправителя.";
           reference
             "RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
              Reflect Octets and Symmetrical Size Features";
         }
         bit IKEv2Derived {
           position 7;
           description
             "В этом режиме общий ключ выводится из защищённой связи (SA)
              протокола Internet Key Exchange Protocol Version 2 (IKEv2).";
           reference
             "RFC 7717: IKEv2-Derived Shared Secret Key for
              the One-Way Active Measurement Protocol (OWAMP)
              and Two-Way Active Measurement Protocol (TWAMP)";
         }
       }
       description
         "задаёт настраиваемые режимы TWAMP-Mode, поддерживаемые при
          организации соединения TWAMP-Control между Control-Client
          и Server. В разделе 7 RFC 7717 описан реестр TWAMP-Modes и
          указаны спецификации форматов.";
     }

     typedef control-client-connection-state {
       type enumeration {
         enum active {
           description
             "Указывает активное соединение TWAMP-Control с сервером.";
         }
         enum idle {
           description
             "Указывает неактивное соединение TWAMP-Control с сервером.";
         }
       }
       description
         "Указывает состояние соединения TWAMP-Control у Control-Client.";
     }

     typedef test-session-state {
       type enumeration {
         enum accepted {
           value 0;
           description
             "Указывает воспринятый запрос сессии TWAMP-Test.";
         }
         enum failed {
           value 1;
           description
             "Указывает отказ для сессии TWAMP-Test по неуказанной
              причине (catch-all).";
         }
         enum internal-error {
           value 2;
           description
             "Указывает отказ для сессии TWAMP-Test в результате
              внутренней ошибки.";
         }
         enum not-supported {
           value 3;
           description
             "Указывает отказ для сессии TWAMP-Test по причине того,
              что некоторые аспекты запроса сессии не поддерживаются.";
         }
         enum permanent-resource-limit {
           value 4;
           description
             "Указывает отказ для сессии TWAMP-Test по причине
              постоянной ограниченности ресурсов.";
         }
         enum temp-resource-limit {
           value 5;
           description
             "Указывает отказ для сессии TWAMP-Test по причине
              временной ограниченности ресурсов.";
         }
       }
       description
         "Указывает состояние сессии TWAMP-Test у Control-Client.";
     }

     typedef server-ctrl-connection-state {
       type enumeration {
         enum active {
           description
             "Указывает активное соединение TWAMP-Control с
              Control-Client.";
         }
         enum servwait {
           description
             "Указывает, что соединение TWAMP-Control с Control-Client
              находится в состоянии SERVWAIT, как указано в параграфе
              3.1 RFC 5357.";
           reference
             "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP),
                        параграф 3.1";
         }
       }
       description
         "Указывает состояние соединения TWAMP-Control на сервере.";
     }

     typedef sender-session-state {
       type enumeration {
         enum active {
           description
             "Указывает, что сессия TWAMP-Test активна.";
         }
         enum failure {
           description
             "Указывает отказ сессии TWAMP-Test.";
         }
       }
       description
         "Указывает состояние сессии TWAMP-Test у Session-Sender.";
     }

     typedef padding-fill-mode {
       type enumeration {
         enum zero {
           description
             "Пакеты TWAMP-Test дополняются нулями.";
         }
         enum random {
           description
             "Пакеты TWAMP-Test дополняются псевдослучайными числами.";
         }
       }
       description
         "Указывает тип заполнения в пакетах TWAMP-Test.";
     }

     typedef dynamic-port-number {
       type inet:port-number {
         range "49152..65535";
       }
       description
         "Диапазон динамических номеров порта.";
     }

     /*
      * Функции
      */

     feature control-client {
       description
         "Указывает, что устройство поддерживает конфигурацию 
          логического элемента TWAMP Control-Client.";
     }

     feature server {
       description
         "Указывает, что устройство поддерживает конфигурацию 
          логического элемента TWAMP Server.";
     }

     feature session-sender {
       description
         "Указывает, что устройство поддерживает конфигурацию 
          логического элемента TWAMP Session-Sender.";
     }

     feature session-reflector {
       description
         "Указывает, что устройство поддерживает конфигурацию 
          логического элемента TWAMP Session-Reflector.";
     }

     /*
      * Группы узлов с многократным использованием
      */

     grouping key-management {
       list key-chain {
         key "key-id";
         leaf key-id {
           type string {
             length "1..80";
           }
           description
             "KeyID применяется для соединения TWAMP-Control. Согласно
              параграфу 3.1 в RFC 4656, KeyID является строкой UTF-8 
              размером до 80 октетов и служит для выбора общего секрета,
              который клиент Control-Client хочет применять для
              аутентификации или шифрования'.";
         }
         leaf secret-key {
           type binary;
           description
             "Секретный ключ, соответствующий KeyID для этого соединения
              TWAMP-Control.";
         }
         description
           "Связывает KeyID с секретными ключами в соединении TWAMP-Control.";
       }
       description
         "Применяется сервером и Control-Client для управления ключами 
          TWAMP-Control.";
     }

     grouping maintenance-statistics {
       leaf sent-packets {
         type uint32;
         config false;
         description
           "Указывает число переданных пакетов.";
       }
       leaf rcv-packets {
         type uint32;
         config false;
         description
           "Указывает число принятых пакетов .";
       }
       leaf last-sent-seq {
         type uint32;
         config false;
         description
           "Указывает последний переданный порядковый номер.";
       }
       leaf last-rcv-seq {
         type uint32;
         config false;
         description
           "Указывает последний принятый порядковый номер .";
       }
       description
         "Используется для статистики обслуживания TWAMP-Test.";
     }

     grouping count {
       leaf count {
         type uint8 {
           range "10..31";
         }
         default "15";
         description
           "Параметр передаётся клиенту Control-Client как часть
            сообщения Server Greeting и служит для вывода ключа по
            общему секрету в соответствии с параграфом 3.1 в RFC 4656.
            (это ДОЛЖНА быть степень числа 2 не меньше 1024). Значение 
            определяет указанная степень. Например, указание здесь 
            числа 20 означает 2^20 = 1048576. По умолчанию задано 15,
            2^15 = 32768.";
       }
       description
         "Структуры данных многократного использования для счётчиков, 
          применяемые в Server и Control-Client.";
     }

     grouping max-count-exponent {
       leaf max-count-exponent {
         type uint8 {
           range "10..31";
         }
         default "20";
         description
           "Ограничивает максимальное значение Count, которое ДОЛЖНО
            быть степенью числа 2 и не меньше 1024 в соответствии с 
            RFC 5357. Задаётся указанием степени. Например, 10 означает
            максимальное значение счётчика 2^10 = 1024. По умолчанию 
            задано 20, 2^20 = 1048576.

            TWAMP Server использует это значение в сообщении
            Server Greeting, передаваемом клиенту Control-Client.

            TWAMP Control-Client использует заданное значение для 
            предотвращения DoS-атак1) путём разрыва управляющего соединения
            с сервером при получении сообщения Server-Greeting с Count 
            больше заданного максимума (раздел 6 в RFC 5357).

            Кроме того, в соответствии с разделом 6 в RFC 5357

            'Если атакующий установит максимальное значение Count
            (2**32), атакуемая система «остановится» на продолжительное
            время, пытаясь создать ключи. Поэтому совместимым с TWAMP
            системам СЛЕДУЕТ иметь конфигурационную возможность
            ограничивать максимальное значение Count. По умолчанию для
            Count СЛЕДУЕТ задавать максимальное значение 32768.'

            В случае этого документа для max-count-exponent по умолчанию
            СЛЕДУЕТ устанавливать значение 15, соответствующее 
            максимальному значение 2**15 или 32768.

            RFC 5357 не уточняет «продолжительное время», но ясно, что 
            оно зависит от доступных вычислительных ресурсов и операторам
            нужно учитывать это при оценке безопасности.";
       }
       description
         "Многократно применяемая структура данных для max-count 
          используется в контейнерах сервера и Control-Client.";
     }


     /*
      * Узлы данных конфигурации
      */
     container twamp {
       description
         "Конфигурация логических элементов TWAMP состоит из 4 моделей,
          соответствующих 4 логическим элементам TWAMP - Control-Client, 
          Server, Session-Sender, Session-Reflector на рисунке 1 в 
          RFC 8913.";
       container client {
         if-feature "control-client";
         description
           "Конфигурация логического элемента TWAMP Control-Client.";
         leaf admin-state {
           type boolean;
           default "true";
           description
             "Указывает, может ли устройство быть TWAMP Control-Client.";
         }
         list mode-preference-chain {
           key "priority";
           unique "mode";
           leaf priority {
             type uint16;
             description
               "Указывает приоритет режима Control-Client 16-битовым 
                целым числом без знака. Значения приоритета начинаются с
                0 (высший) и увеличиваются на 1 для последующих.";
           }
           leaf mode {
             type twamp-modes;
             description
               "Поддерживаемые режимы TWAMP-Mode соответствующие 
                приоритету.";
           }
           description
             "Указывает предпочтительный порядок использования клиентом 
              Control-Client поддерживаемых TWAMP-Mode.

              Из режимов, указанных в сообщении TWAMP Server Greeting 
              (см. рисунок 2 в RFC 7717), Control-Client ДОЛЖЕН выбрать
              наиболее приоритетный в списке mode-preference-chain.";
         }
         uses key-management;
         list ctrl-connection {
           key "name";
           description
             "Список управляющих соединений TWAMP Control-Client.
              Каждая запись списка описывает соединение, которое будет
              инициировано этим Control-Client.";
           leaf name {
             type string;
             description
               "Уникальное имя, служащее ключом для указания отдельного
                соединения TWAMP-Control на устройстве Control-Client.";
           }
           leaf client-ip {
             type inet:ip-address;
             description
               "IP-адрес локального устройства Control-Client для
                включения в поле source IP заголовка IP в пакетах
                TWAMP-Control (TCP), относящихся к этому управляющему
                соединению. Если параметр не задан, устройству НУЖНО
                выбрать один из своих адресов IP.";
           }
           leaf server-ip {
             type inet:ip-address;
             mandatory true;
             description
               "IP-адрес удалённого устройства Server, с которым 
                инициируется соединение TWAMP-Control.";
           }
           leaf server-tcp-port {
             type inet:port-number;
             default "862";
             description
               "Этот параметр задаёт номер порта TCP, который будет 
                применяться в этом исходящем соединении TWAMP-Control.
                Обычно это общеизвестный порт TWAMP-Control (862),
                заданный в RFC 5357. Однако известны реализации TWAMP,
                созданные до выделения этого номера порта. В таких
                ранних реализациях номер порта можно задавать. Этот
                параметр нужен для совместимости с такими реализациями.";
           }
           leaf control-packet-dscp {
             type inet:dscp;
             default "0";
             description
               "Значение кода дифференцированного обслуживания (DSCP) для
                включения в заголовок IP пакетов TWAMP-Control (TCP),
                создаваемых этим Control-Client.";
           }
           leaf key-id {
             type string {
               length "1..80";
             }
             description
               "Указывает значение KeyID выбранное для этого
                соединения TWAMP-Control.";
           }
           uses max-count-exponent;
           leaf client-tcp-port {
             type inet:port-number;
             config false;
             description
               "Указывает порт отправителя TCP в пакетах TWAMP-Control,
                относящихся к этому управляющему соединения.";
           }
           leaf server-start-time {
             type uint64;
             config false;
             description
               "Указывает время Start-Time, анонсированное сервером в
                сообщении Server-Start (RFC 4656, параграф 3.1), которое
                представляет время, когда текущий экземпляр сервера 
                начал работу. Метка использует формат RFC 5905 в 
                соответствии с параграфом 4.1.2 RFC 4656.";
             reference
               "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
                параграфы 3.1 и 4.1.2
                RFC 5905: Network Time Protocol Version 4: Protocol and
                Algorithms Specification";
           }
           leaf repeat-count {
             type uint64;
             config false;
             description
               "Указывает число повторов сеанса тестирования. При работе
                теста это значение будет больше 0. Если параметр repeat
                не равен 0, это значение будет не больше repeat.";
           }
           leaf state {
             type control-client-connection-state;
             config false;
             description
               "Указывает текущий статус соединения TWAMP-Control.";
           }
           leaf selected-mode {
             type twamp-modes;
             config false;
             description
               "режимы TWAMP-Mode, выбранные Control-Client для этого
                управляющего соединения в соответствии с полем Mode в
                сообщении Set-Up-Response.";
             reference
               "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
                          параграф 3.1";
           }
           leaf token {
             type binary {
               length "64";
             }
             config false;
             description
               "64 октета, содержащие конкатенацию 16 октетов Challenge, 
                16 октетов сеансового ключа шифрования AES и 32 октетов
                сеансового ключа аутентификации HMAC-SHA1 (см. последний
                абзац параграфа 6.10 в RFC 4656).

                Если выбран режим, заданный в RFC 7717 (selected-mode), 
                размер token ограничен 16 октетами.";
             reference
               "RFC 4656: A One-way Active Measurement Protocol (OWAMP),
                          параграф 6.10
                RFC 7717: IKEv2-Derived Shared Secret Key for the
                One-Way Active Measurement Protocol (OWAMP) and
                Two-Way Active Measurement Protocol (TWAMP)";
           }
           leaf client-iv {
             type binary {
               length "16";
             }
             config false;
             description
               "Указывает вектор инициализации Control-Client (Client-IV), 
                создаваемый клиентом случайным образом (RFC 4656):

                'Значение Client-IV просто должно быть уникальным (т. е.
                ДОЛЖНО различаться в каждой сессии, использующей тот же
                секретный ключ. Простым способом решения этой задачи без
                использования громоздкого состояния является создание 
                Client-IV с использованием криптографически защищённого
                источника случайных чисел.'

                Если выбран режим, заданный в RFC 7717 (selected-mode), 
                размер client-iv ограничен 12 октетами.";
             reference
               "RFC 4656: A One-way Active Measurement Protocol (OWAMP)
                RFC 7717: IKEv2-Derived Shared Secret Key for the
                One-Way Active Measurement Protocol (OWAMP) and
                Two-Way Active Measurement Protocol (TWAMP)";
           }
           list test-session-request {
             key "name";
             description
               "Информация, связанная с Control-Client для этой 
                сессии тестирования.";
             leaf name {
               type string;
               description
                 "Уникальное имя для указания этой сессии TWAMP-Test
                  на Control-Client.";
             }
             leaf sender-ip {
               type inet:ip-address;
               description
                 "IP-адрес устройства Session-Sender, помещаемый в поле
                  source IP заголовка IP в пакетах TWAMP-Test (UDP), 
                  связанных с этой сессией тестирования. Это значение
                  помещается в поле Sender Address сообщения
                  Request-TW-Session.

                  Если значение не задано, устройству НУЖНО выбрать один
                  из своих адресов IP.";
             }
             leaf sender-udp-port {
               type union {
                 type dynamic-port-number;
                 type enumeration {
                   enum autoallocate {
                     description
                       "Указывает, что Control-Client будет автоматически
                        выделять номер порта TWAMP-Test (UDP) из
                        диапазона динамических портов.";
                   }
                 }
               }
               default "autoallocate";
               description
                 "Номер порта UDP, используемый Session-Sender для этой
                  сессии TWAMP-Test. Номер должен браться из
                  диапазона динамических номеров.

                  По умолчанию устройству Control-Client НУЖНО выделять
                  номер порта UDP для сессии TWAMP-Test автоматически.

                  Заданное (или выделенное автоматически) значение
                  анонсируется в поле Sender Port сообщения
                  Request-TW-Session (см. параграф 3.5 в RFC 5357).  
                  Отметим, что при автоматическом выделении номера порта
                  для сессии и параметре repeat, указывающем повтор 
                  теста устройство может выделить другой номер при
                  согласование следующей (повторной) итерации сессии.";
             }
             leaf reflector-ip {
               type inet:ip-address;
               mandatory true;
               description
                 "Адрес IP, относящийся к удалённому устройству
                  Session-Reflector, с которым организован сеанс 
                  TWAMP-Test. Это значение помещается в поле 
                  Receiver Address сообщения Request-TW-Session.";
             }
             leaf reflector-udp-port {
               type inet:port-number {
                 range "862 | 49152..65535";
               }
               description
                 "Этот параметр задаёт номер порта UDP, применяемый 
                  Session-Reflector для этой сессии TWAMP-Test. По 
                  умолчанию номер берётся из динамического диапазона
                  и помещается в поле Receiver Port сообщения Request-
                  TW-Session. МОЖНО указать общеизвестный порт (862).";
               reference
                 "RFC 8545: Well-Known Port Assignments for the One-Way
                  Active Measurement Protocol (OWAMP) and the Two-Way
                  Active Measurement Protocol (TWAMP)";
             }
             leaf timeout {
               type uint64;
               units "seconds";
               default "2";
               description
                 "Время (в секундах), в течение которого устройству
                  Session-Reflector следует продолжать отвечать на
                  пакеты, относящиеся к этой сессии TWAMP-Test, после 
                  приёма сообщения Stop-Sessions TWAMP-Control.

                  Это значение помещается в поле Timeout сообщения
                  Request-TW-Session.";
               reference
                 "RFC 5357: A Two-Way Active Measurement Protocol
                  (TWAMP), параграф 3.5";
             }
             leaf padding-length {
               type uint32 {
                 range "64..4096";
               }
               description
                 "Число байтов заполнения, добавляемых в пакеты
                  TWAMP-Test (UDP), создаваемые Session-Sender.

                  Это значение помещается в поле Padding Length
                  сообщения Request-TW-Session.";
               reference
                 "RFC 4656: A One-way Active Measurement Protocol
                  (OWAMP), параграф 3.5";
             }
             leaf test-packet-dscp {
               type inet:dscp;
               default "0";
               description
                 "Значение DSCP, помещаемое в заголовок IP пакетов
                  TWAMP-Test, создаваемых Session-Sender, и в заголовок
                  UDP пакетов отклика TWAMP-Test, создаваемых устройством
                  Session-Reflector, для этого сеанса тестирования.

                  Это значение помещается в поле Type-P Descriptor
                  сообщения Request-TW-Session.";
               reference
                 "RFC 5357: A Two-Way Active Measurement Protocol
                  (TWAMP)";
             }
             leaf start-time {
               type uint64;
               default "0";
               description
                 "Время начала сессии (но не раньше времени ввода 
                  команды TWAMP Start-Sessions, параграф 3.4 RFC 5357).

                  Значение start-time помещается в поле Start Time
                  сообщения Request-TW-Session.

                  Временная метка соответствует формату RFC 5905, как
                  указано в параграфе 3.5 RFC 4656.

                  Принятое по умолчанию значение 0 указывает, что сессия
                  начнётся сразу при получении сообщения Start-Sessions.";
             }
             leaf repeat {
               type uint32 {
                 range "0..4294967295";
               }
               default "0";
               description
                 "Это значение управляет повтором сессии TWAMP-Test. По
                  завершении сеанса проверяется значение этого параметра.

                  Принятое по умолчанию значение 0 указывает, что повтор
                  сессии НЕДОПУСТИМ.

                  Если repeat имеет значение от 1 до 4294967294, сеанс
                  тестирования НУЖНО повторять с использованием значения
                  repeat-interval и родительское соединение TWAMP-Control
                  для этой сессии перезапускается для согласования нового
                  экземпляра сессии TWAMP-Test.

                  Значение 4294967295 указывает, что сеанс НУЖНО
                  повторять безостановочно с использованием параметра
                  repeat-interval, не уменьшая  значения счётчика.";
             }
             leaf repeat-interval {
               when "../repeat!='0'" {
                 description
                   "Этот параметр управляет временем повтора сессий 
                    TWAMP-Test при значении repeat > 0.

                    При repeat-interval = 0 согласование новой сессии
                    НУЖНО начинать сразу после завершения прежней. В
                    иных случаях Control-Client будет ждать в течение
                    заданного repeat-interval числа секунд перед началом
                    согласования нового экземпляра сессии TWAMP-Test.";
               }
               type uint32;
               units "seconds";
               default "0";
               description
                 "Интервал повторения в секундах.";
             }
             list pm-reg-list {
               key "pm-index";
               leaf pm-index {
                 type uint16;
                 description
                   "Значение числового индекса Registered Metric в
                    Performance Metrics Registry (см. RFC 8911).
                    Выходная статистика задаётся соответствующей 
                    записью реестра.";
               }
               description
                 "Список индексов Performance Metrics Registry,
                  передающих характеристики потока пакетов с одним
                  или несколькими измеряемыми показателями.

                  Все элементы pm-reg-list ДОЛЖНЫ иметь общие
                  характеристики потока, чтобы их можно было
                  комбинировать для указания всех параметров, измеряемых
                  в одном потоке.";
               reference
                 "RFC 8911: Registry for Performance Metrics";
             }
             leaf state {
               type test-session-state;
               config false;
               description
                 "Указывает состояние сессии TWAMP-Test - принятый 
                  запрос или ошибка.";
               reference
                 "RFC 5357: A Two-Way Active Measurement Protocol
                  (TWAMP), параграф 3.5";
             }
             leaf sid {
               type string;
               config false;
               description
                 "Идентификатор сессии (SID), выделенный сервером для
                  этого сеанса TWAMP-Test и возвращаемый клиенту
                  Control-Client в поле SID сообщения Accept-Session.";
               reference
                 "RFC 6038: Two-Way Active Measurement Protocol (TWAMP)
                  Reflect Octets and Symmetrical Size
                  Features, параграф 4.3";
             }
           }
         }
       }
       container server {
         if-feature "server";
         description
           "Конфигурация логического элемента TWAMP Server.";
         leaf admin-state {
           type boolean;
           default "true";
           description
             "Указывает, может ли устройство работать как TWAMP Server.";
         }
         leaf server-tcp-port {
           type inet:port-number;
           default "862";
           description
             "Задаёт общеизвестный порт TCP, используемый TWAMP-Control.
              Сервер прослушивает на этом порту входящие соединения
              TWAMP-Control. Хотя порт задан фиксированным значением
              (862) в RFC 5357, имеются реализации TWAMP, созданные
              до выделения этого номера, которые могут указывать порт
              в конфигурации. Параметр предназначен для совместимости
              с такими реализациями.";
         }
         leaf servwait {
           type uint32 {
             range "1..604800";
           }
           units "seconds";
           default "900";
           description
             "Тайм-аут сессии TWAMP-Control (TCP) в секундах.
              (параграф 3.1 в RFC 5357)

              'Server МОЖЕТ прервать любое организованное управляющее
              при отсутствии приёма связанных с ним пакетов в течение
              SERVWAIT секунд.'";
         }
         leaf control-packet-dscp {
           type inet:dscp;
           description
             "Значение DSCP, помещаемое в заголовок IP пакетов
              TWAMP-Control (TCP), генерируемых сервером.

              В параграфе 3.1 RFC 5357 указано, что серверу СЛЕДУЕТ
              применять значение DSCP из пакета TCP SYN от клиента
              Control-Client. Однако на практике TWAMP обычно 
              реализуется с использованием стека TCP общего назначения
              в базовой операционной системе, который может не давать
              пользователю таких сведений. Поэтому не всегда возможно
              реализовать поведение, описанное в RFC 5357, в переносимой
              между ОС версии TWAMP.

              По умолчанию для этого элемента не применяется установка 
              DSCP из TCP SYN от Control-Client.";
           reference
             "RFC 5357: A Two-Way Active Measurement Protocol (TWAMP),
              параграф 3.1";
         }
         uses count;
         uses max-count-exponent;
         leaf modes {
           type twamp-modes;
           description
             "Битовая маска режимов TWAMP-Mode, которые этот экземпляр
              сервера готов поддерживать (реестр IANA TWAMP-Modes).";
         }
         uses key-management;
         list ctrl-connection {
           key "client-ip client-tcp-port server-ip server-tcp-port";
           config false;
           description
             "Список всех входящих соединений TWAMP-Control (TCP).";
           leaf client-ip {
             type inet:ip-address;
             description
               "IP-адрес удалённого устройства Control-Client, который
                указан в поле source IP пакетов TWAMP-Control (TCP), 
                относящихся к этому управляющему соединению.";
           }
           leaf client-tcp-port {
             type inet:port-number;
             description
               "Номер порта отправителя TCP в пакетах TWAMP-Control
                (TCP) этого управляющего соединения.";
           }
           leaf server-ip {
             type inet:ip-address;
             description
               "IP-адрес локального устройства Server, который указан
                в поле destination IP пакетов TWAMP-Control (TCP) в
                этом управляющем соединении.";
           }
           leaf server-tcp-port {
             type inet:port-number;
             description
               "Порт получателя TCP в пакетах TWAMP-Control (TCP) этого
                управляющего соединения. Обычно это совпадает с
                server-tcp-port в контейнере twamp/server. Однако если
                пользователь изменит server/server-tcp-port после
                организации управляющего соединения, это значение будет
                указывать фактический номер server-tcp-port.";
           }
           leaf state {
             type server-ctrl-connection-state;
             description
               "Указывает статус соединения TWAMP-Control на сервере.";
           }
           leaf control-packet-dscp {
             type inet:dscp;
             description
               "Значение DSCP в заголовке IP пакетов TWAMP-Control (TCP),
                передаваемых сервером в этом управляющем соединении. 
                Обычно это совпадает со значением параметра
                control-packet-dscp в контейнере twamp/server. Однако
                если пользователь поменяет server/dscp уже после
                организации соединения это доступное лишь для чтения
                значение будет показывать фактическое поле DSCP в этом
                соединении TWAMP-Control.";
           }
           leaf selected-mode {
             type twamp-modes;
             description
               "Режим, выбранный для этого соединения TWAMP-Control
                установкой поля Mode в сообщении Set-Up-Response.";
           }
           leaf key-id {
             type string {
               length "1..80";
             }
             description
               "Значение KeyID для данного соединения TWAMP-Control,
                которое выбрал Control-Client.";
           }
           uses count {
             description
               "Значение Count в данном соединении TWAMP-Control.
                Обычно оно совпадает со значением в контейнере
                twamp/server. Однако если пользователь изменит 
                server/count после организации соединения, это
                доступное лишь для чтения поле будет указывать
                фактическое значение счётчика в данном соединении
                TWAMP-Control.";
           }
           uses max-count-exponent {
             description
               "Доступное лишь для чтения поле, указывающее фактическое 
                значение max-count в этом управляющем соединении. Обычно
                оно совпадает со значением в контейнере twamp/server.";
           }
           leaf salt {
             type binary {
               length "16";
             }
             description
               "Параметр, используемый для вывода ключа из общего 
                секрета, как указано в параграфе 3.1 RFC 4656.
                Передаётся клиенту Control-Client как часть сообщения
                Server Greeting.";
           }
           leaf server-iv {
             type binary {
               length "16";
             }
             description
               "Вектор инициализации сервера (Server-IV), создаваемый
                сервером случайным образом.";
           }
           leaf challenge {
             type binary {
               length "16";
             }
             description
               "Случайная последовательность октетов, создаваемая
                сервером. Как описано в client/token, Challenge 
                применяется Control-Client для подтверждения 
                владения общим секретом.";
           }
         }
       }
       container session-sender {
         if-feature "session-sender";
         description
           "Конфигурация логического объекта TWAMP Session-Sender.";
         leaf admin-state {
           type boolean;
           default "true";
           description
             "Указывает, может ли устройство работать как 
              TWAMP Session-Sender.";
         }
         list test-session {
           key "name";
           description
             "Список тестовых сессий TWAMP Session-Sender.";
           leaf name {
             type string;
             description
               "Уникальное имя этой сессии TWAMP-Test, используемое для
                её идентификации логическим объектом Session-Sender.";
           }
           leaf ctrl-connection-name {
             type string;
             config false;
             description
               "Имя родительского соединения TWAMP-Control, отвечающего
                за согласование этой сессии TWAMP-Test.";
           }
           leaf fill-mode {
             type padding-fill-mode;
             default "zero";
             description
               "Указывает применение для заполнения пакетов TWAMP-Test
                (UDP) (1) псевдослучайных чисел или (2) нулей, как 
                указано в параграфе 4.2.1 RFC 5357.";
           }
           leaf number-of-packets {
             type uint32;
             mandatory true;
             description
               "Общее число пакетов TWAMP-Test (UDP), передаваемых 
                устройством Session-Sender в этом сеансе тестирования.";
           }
           choice packet-distribution {
             description
               "Указывает распределение, используемое для передачи
                пакетов TWAMP-Test (UDP).";
             case periodic {
               leaf periodic-interval {
                 type decimal64 {
                   fraction-digits 5;
                 }
                 units "seconds";
                 mandatory true;
                 description
                   "Указывает интервал (в секундах) между первыми 
                    битами пакетов TWAMP-Test (UDP) в этой сессии.";
                 reference
                   "RFC 3432: Network performance measurement with
                    periodic streams";
               }
             }
             case poisson {
               leaf lambda {
                 type decimal64 {
                   fraction-digits 5;
                 }
                 units "seconds";
                 mandatory true;
                 description
                   "Указывает средний интервал (в секундах) между
                    пакетами с распределением Пуассона. При расчёте
                    используется величина, обратная lambda и размер
                    пакета TWAMP-Test (зависит от режима и заполнения).";
                 reference
                   "RFC 2330: Framework for IP Performance Metrics";
               }
               leaf max-interval {
                 type decimal64 {
                   fraction-digits 5;
                 }
                 units "seconds";
                 description
                   "Задаёт максимальное время (в секундах) между
                    передачей пакетов.";
                 reference
                   "RFC 7312: Advanced Stream and Sampling Framework
                    for IP Performance Metrics (IPPM)";
               }
             }
           }
           leaf state {
             type sender-session-state;
             config false;
             description
               "Указывает состояние тестовой сессии Session-Sender.";
           }
           uses maintenance-statistics;
         }
       }
       container session-reflector {
         if-feature "session-reflector";
         description
           "Конфигурация логического объекта TWAMP
            Session-Reflector.";
         leaf admin-state {
           type boolean;
           default "true";
           description
             "Указывает, может ли устройство быть 
              TWAMP Session-Reflector.";
         }
         leaf refwait {
           type uint32 {
             range "1..604800";
           }
           units "seconds";
           default "900";
           description
             "Session-Reflector МОЖЕТ прервать любую сессию при 
              отсутствии связанных с ней пакетов в течение REFWAIT
              REFWAIT секунд. Как указано в параграфе 3.1 5357, 
              этот тайм-аут позволяет Session-Reflector освободить
              ресурсы в случае отказа.";
         }
         list test-session {
           key "sender-ip sender-udp-port
                reflector-ip reflector-udp-port";
           config false;
           description
             "Тестовые сессии TWAMP Session-Reflector.";
           leaf sid {
             type string;
             description
               "Автоматически выделенный идентификатор для этой сессии
                TWAMP-Test, уникальный лишь в контексте устройства
                Server/Session-Reflector. Это значение передаётся
                клиенту Control-Client, запросившему сеанс тестирования,
                в поле SID сообщения Accept-Session.";
           }
           leaf sender-ip {
             type inet:ip-address;
             description
               "IP-адрес удалённого устройства, который служит source IP
                в пакетах TWAMP-Test (UDP) этой тестовой сессии.";
           }
           leaf sender-udp-port {
             type dynamic-port-number;
             description
               "Порт отправителя UDP в пакетах TWAMP-Test этой сессии.";
           }
           leaf reflector-ip {
             type inet:ip-address;
             description
               "IP-адрес локального устройства Session-Reflector,
                служащий destination IP в пакетах TWAMP-Test (UDP) 
                данного сеанса тестирования.";
           }
           leaf reflector-udp-port {
             type inet:port-number {
               range "862 | 49152..65535";
             }
             description
               "Порт получателя UDP в пакетах TWAMP-Test (UDP) 
                этой сессии.";
           }
           leaf parent-connection-client-ip {
             type inet:ip-address;
             description
               "IP-адрес устройства Control-Client, который служит
                source IP в пакетах TWAMP-Control (TCP) родительского
                управляющего соединения, согласовавшего эту сессию.";
           }
           leaf parent-connection-client-tcp-port {
             type inet:port-number;
             description
               "Порт отправителя TCP в пакетах TWAMP-Control (TCP) 
                родительского соединения, согласовавшего эту сессию.";
           }
           leaf parent-connection-server-ip {
             type inet:ip-address;
             description
               "IP-адрес сервера, который служит destination IP в 
                пакетах TWAMP-Control (TCP) родительского 
                соединения, согласовавшего эту сессию.";
           }
           leaf parent-connection-server-tcp-port {
             type inet:port-number;
             description
               "Порт получателя TCP, используемый в пакетах 
                TWAMP-Control (TCP) родительского управляющего
                соединения, согласовавшего эту сессию.";
           }
           leaf test-packet-dscp {
             type inet:dscp;
             description
               "Значение DSCP в заголовке IP пакетов TWAMP-Test
                (UDP), относящихся к этой сессии.";
           }
           uses maintenance-statistics;
         }
       }
     }
   }
   <CODE ENDS>

1Denial-of-service – отказ в обслуживании.

6. Примеры моделей данных

В этом разделе представлены простые, но полные примеры всех 4 объектов с рисунка 1, основанные на модуле YANG из раздела 5. Примеры иллюстрируют природу объекта, но нацелены на самодостаточность, т. е. их выполнение в реальной реализации TWAMP приведёт к корректной настройке тестовых сессий. Для полноты представлены примеры IPv4 и IPv6. В примерах применяется язык XML [W3C.REC-xml-20081126]. Более подробные примеры с параметрами аутентификации приведены в Приложении A.

6.1. Control-Client

На рисунке 8 показан пример конфигурации, разрешающий работу Control-Client (client/admin-state). В реальной реализации, следующей рисунку 2, это позволит инициировать соединения TWAMP-Control и сессии TWAMP-Test.

<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <client>
      <admin-state>true</admin-state>
    </client>
  </twamp>
</config>

Рисунок 8. Экземпляр XML, разрешающий работу Control-Client.

Приведённый ниже пример показывает Control-Client с двумя экземплярами client/ctrl-connection – RouterA и RouterB. Каждое соединение TWAMP-Control организуется со своим сервером. Управляющее соединение RouterA включает 2 запроса сессий тестирования, соединение RouterB не подаёт таких запросов.

   <?xml version="1.0" encoding="utf-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <client>
         <admin-state>true</admin-state>
         <ctrl-connection>
           <name>RouterA</name>
           <client-ip>203.0.113.1</client-ip>
           <server-ip>203.0.113.2</server-ip>
           <test-session-request>
             <name>Test1</name>
             <sender-ip>203.0.113.3</sender-ip>
             <sender-udp-port>54001</sender-udp-port>
             <reflector-ip>203.0.113.4</reflector-ip>
             <reflector-udp-port>50001</reflector-udp-port>
             <start-time>0</start-time>
           </test-session-request>
           <test-session-request>
             <name>Test2</name>
             <sender-ip>203.0.113.1</sender-ip>
             <sender-udp-port>54001</sender-udp-port>
             <reflector-ip>203.0.113.2</reflector-ip>
             <reflector-udp-port>50001</reflector-udp-port>
             <start-time>0</start-time>
           </test-session-request>
         </ctrl-connection>
         <ctrl-connection>
           <name>RouterB</name>
           <client-ip>203.0.113.1</client-ip>
           <server-ip>203.0.113.3</server-ip>
         </ctrl-connection>
       </client>
     </twamp>
   </config>
   <?xml version="1.0" encoding="utf-8"?>
   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <client>
         <admin-state>true</admin-state>
         <ctrl-connection>
           <name>RouterA</name>
           <client-ip>2001:db8:203:0:113::1</client-ip>
           <server-ip>2001:db8:203:0:113::2</server-ip>
           <test-session-request>
             <name>Test1</name>
             <sender-ip>2001:db8:203:1:113::3</sender-ip>
             <sender-udp-port>54000</sender-udp-port>
             <reflector-ip>2001:db8:203:1:113::4</reflector-ip>
             <reflector-udp-port>55000</reflector-udp-port>
             <start-time>0</start-time>
           </test-session-request>
           <test-session-request>
             <name>Test2</name>
             <sender-ip>2001:db8:203:0:113::1</sender-ip>
             <sender-udp-port>54001</sender-udp-port>
             <reflector-ip>2001:db8:203:0:113::2</reflector-ip>
             <reflector-udp-port>55001</reflector-udp-port>
             <start-time>0</start-time>
           </test-session-request>
         </ctrl-connection>
         <ctrl-connection>
           <name>RouterB</name>
           <client-ip>2001:db8:203:0:113::1</client-ip>
           <server-ip>2001:db8:203:0:113::3</server-ip>
         </ctrl-connection>
       </client>
     </twamp>
   </config>

6.2. Сервер

На рисунке 9 показан пример конфигурации Server со включённым server/admin-state, что позволяет устройству, следующему рисунку 2, отвечать на соединения TWAMP-Control и сессии TWAMP-Test.

<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <server>
      <admin-state>true</admin-state>
    </server>
  </twamp>
</config>

Рисунок 9. Экземпляр XML, разрешающий работу сервера.

Приведённый ниже пример представляет Server с соединением TWAMP-Control, соответствующим имени (client/ctrl-connection/name) RouterA, представленному в параграфе 6.1.

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <server>
         <admin-state>true</admin-state>
         <ctrl-connection>
           <client-ip>203.0.113.1</client-ip>
           <client-tcp-port>16341</client-tcp-port>
           <server-ip>203.0.113.2</server-ip>
           <server-tcp-port>862</server-tcp-port>
           <state>active</state>
         </ctrl-connection>
       </server>
     </twamp>
   </data>

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <server>
         <admin-state>true</admin-state>
         <ctrl-connection>
           <client-ip>2001:db8:203:0:113::1</client-ip>
           <client-tcp-port>16341</client-tcp-port>
           <server-ip>2001:db8:203:0:113::2</server-ip>
           <server-tcp-port>862</server-tcp-port>
           <state>active</state>
         </ctrl-connection>
       </server>
     </twamp>
   </data>

6.3. Session-Sender

На рисунке 10 показан пример конфигурации Session-Sender со включённым session-sender/admin-state, что позволяет устройству, следующему рисунку 2, инициировать соединения TWAMP-Control и сессии TWAMP-Test.

<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-sender>
      <admin-state>true</admin-state>
    </session-sender>
  </twamp>
</config>

Рисунок 10. Экземпляр XML, разрешающий работу Session-Sender.

Приведённый ниже пример конфигурации показывает Session-Sender с 2 сессиями TWAMP-Test, представленными в параграфе 6.1.

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <session-sender>
         <admin-state>true</admin-state>
         <test-session>
           <name>Test1</name>
           <ctrl-connection-name>RouterA</ctrl-connection-name>
           <number-of-packets>900</number-of-packets>
           <periodic-interval>1</periodic-interval>
         </test-session>
         <test-session>
           <name>Test2</name>
           <ctrl-connection-name>RouterA</ctrl-connection-name>
           <number-of-packets>900</number-of-packets>
           <lambda>1</lambda>
           <max-interval>2</max-interval>
         </test-session>
       </session-sender>
     </twamp>
   </data>

6.4. Session-Reflector

На рисунке 11 показан пример конфигурации Session-Reflector со включённым session-reflector/admin-state, что позволяет устройству, следующему рисунку 2, отвечать на сессии TWAMP-Test.

<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
    <session-reflector>
      <admin-state>true</admin-state>
    </session-reflector>
  </twamp>
</config>

Рисунок 11. Экземпляр XML, разрешающий работу Session-Reflector.

Приведённый ниже пример показывает 2 сессии Session-Reflector TWAMP-Test, соответствующие представленным в параграфе 6.3.

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <session-reflector>
         <admin-state>true</admin-state>
         <test-session>
           <sender-ip>203.0.113.3</sender-ip>
           <sender-udp-port>54000</sender-udp-port>
           <reflector-ip>203.0.113.4</reflector-ip>
           <reflector-udp-port>50001</reflector-udp-port>
           <sid>1232</sid>
           <parent-connection-client-ip>203.0.113.1</parent-connection-\
   client-ip>
           <parent-connection-client-tcp-port>16341</parent-connection-\
   client-tcp-port>
           <parent-connection-server-ip>203.0.113.2</parent-connection-\
   server-ip>
           <parent-connection-server-tcp-port>862</parent-connection-se\
   rver-tcp-port>
           <sent-packets>2</sent-packets>
           <rcv-packets>2</rcv-packets>
           <last-sent-seq>1</last-sent-seq>
           <last-rcv-seq>1</last-rcv-seq>
         </test-session>
         <test-session>
           <sender-ip>203.0.113.1</sender-ip>
           <sender-udp-port>54001</sender-udp-port>
           <reflector-ip>192.0.2.2</reflector-ip>
           <reflector-udp-port>50001</reflector-udp-port>
           <sid>178943</sid>
           <parent-connection-client-ip>203.0.113.1</parent-connection-\
   client-ip>
           <parent-connection-client-tcp-port>16341</parent-connection-\
   client-tcp-port>
           <parent-connection-server-ip>203.0.113.2</parent-connection-\
   server-ip>
           <parent-connection-server-tcp-port>862</parent-connection-se\
   rver-tcp-port>
           <sent-packets>21</sent-packets>
           <rcv-packets>21</rcv-packets>
           <last-sent-seq>20</last-sent-seq>
           <last-rcv-seq>20</last-rcv-seq>
         </test-session>
       </session-reflector>
     </twamp>
   </data>

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <session-reflector>
         <admin-state>true</admin-state>
         <test-session>
           <sender-ip>203.0.113.3</sender-ip>
           <sender-udp-port>54000</sender-udp-port>
           <reflector-ip>203.0.113.4</reflector-ip>
           <reflector-udp-port>54001</reflector-udp-port>
           <sid>1232</sid>
           <parent-connection-client-ip>203.0.113.1</parent-connection-\
   client-ip>
           <parent-connection-client-tcp-port>16341</parent-connection-\
   client-tcp-port>
           <parent-connection-server-ip>203.0.113.2</parent-connection-\
   server-ip>
           <parent-connection-server-tcp-port>862</parent-connection-se\
   rver-tcp-port>
           <sent-packets>2</sent-packets>
           <rcv-packets>2</rcv-packets>
           <last-sent-seq>1</last-sent-seq>
           <last-rcv-seq>1</last-rcv-seq>
         </test-session>
         <test-session>
           <sender-ip>203.0.113.1</sender-ip>
           <sender-udp-port>54001</sender-udp-port>
           <reflector-ip>192.0.2.2</reflector-ip>
           <reflector-udp-port>55001</reflector-udp-port>
           <sid>178943</sid>
           <parent-connection-client-ip>203.0.113.1</parent-connection-\
   client-ip>
           <parent-connection-client-tcp-port>16341</parent-connection-\
   client-tcp-port>
           <parent-connection-server-ip>203.0.113.2</parent-connection-\
   server-ip>
           <parent-connection-server-tcp-port>862</parent-connection-se\
   rver-tcp-port>
           <sent-packets>21</sent-packets>
           <rcv-packets>21</rcv-packets>
           <last-sent-seq>20</last-sent-seq>
           <last-rcv-seq>20</last-rcv-seq>
         </test-session>
       </session-reflector>
     </twamp>
   </data>

7. Вопросы безопасности

Фактически все имеющиеся измерительные системы с использованием TWAMP [RFC5357] администрируются одним сетевым оператором. Атаки на измерительную инфраструктуру могут быть организованы третьей стороной для захвата возможности генерации пакетов, искажения измерений или выполнения иных злонамеренных действий.

Заданные этим документом модули YANG определяют схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].

Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

В этом модуле данных YANG определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. по умолчанию config имеет значение true). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены субдеревья и узлы, которые могут быть конфиденциальны или уязвимы.

  • Запись в admin-state может приводить к созданию непредусмотренных тестовых сессий.

  • При записи в узел number-of-packets, определяющий число пакетов, передаваемых в любой конкретной сессии тестирования, большого значения тестовая сессия будет длиться дольше ожидаемого времени.

  • Особо уязвимые узлы включают несколько тайм-аутов, заданных протоколом, для защиту от сессий, которые не активны, но потребляют ресурсы. Параметр REFWAIT управляет прерыванием сессий при отсутствии пакетов, узлы count и max-count-exponent управляют итерациями функции вывода ключей по паролю (Password-Based Key Derivation Function 2 или PBKDF2).

  • Узел dscp с разными маркерами DSCP может вызывать искажение тестового трафика в сети и манипулирование результатом.

  • Узлы в mode-preference-chain, задающие значения mode и priority, которые указывают предпочтительный порядок использования оператором, могут служить для манипуляций с отправкой неаутентифицированного или нешифрованного трафика, что позволяет организовать атаки в пути.

Ограничение доступа к таким узлам позволит сократить возможности организации атак в сетевой среде.

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). Ниже перечислены субдеревья и узлы, которые могут быть конфиденциальны или уязвимы.

  • Заданный в модели узел token с конкатенацией Challenge, AES Session-key (шифрование) и HMAC-SHA1 Session-key (аутентификация) чувствителен в плане конфиденциальности и может использоваться для нарушения работы тестовых сессий. Возможность считывания этого поля следует предоставлять лишь ограниченному числу администраторов тестовой сети.

Модель TWAMP YANG на задаёт операций RPC, как указано в Приложении B, и оставляет определение операций NETCONF RPC за реализациями. При определении таких операций RPC они могут оказаться уязвимыми в некоторых сетевых средах, поэтому важно контролировать доступ к этим операциям.

8. Взаимодействие с IANA

Агентство IANA внесло приведённый ниже идентификатор URI в реестр IETF XML Registry [RFC3688].

   URI:  urn:ietf:params:xml:ns:yang:ietf-twamp
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

Агентство IANA внесло указанный ниже модуль YANG в реестр YANG Module Names [RFC6020].

   Name:  ietf-twamp
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-twamp
   Prefix:  twamp
   Reference:  RFC 8913

9. Литература

9.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>.

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, “Network performance measurement with periodic streams”, RFC 3432, DOI 10.17487/RFC3432, November 2002, <https://www.rfc-editor.org/info/rfc3432>.

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[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>.

[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>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6038] Morton, A. and L. Ciavattone, “Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features”, RFC 6038, DOI 10.17487/RFC6038, October 2010, <https://www.rfc-editor.org/info/rfc6038>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui, “IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)”, RFC 7717, DOI 10.17487/RFC7717, December 2015, <https://www.rfc-editor.org/info/rfc7717>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[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>.

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8545] Morton, A., Ed. and G. Mirsky, Ed., “Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)”, RFC 8545, DOI 10.17487/RFC8545, March 2019, <https://www.rfc-editor.org/info/rfc8545>.

[RFC8911] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. Akhter, “Registry for Performance Metrics”, RFC 8911, DOI 10.17487/RFC8911, November 2021, <https://www.rfc-editor.org/info/rfc8911>.

[UML] ISO/IEC, “Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version 1.4.2”, ISO/IEC 19501:2005, OMG-UML VER 1.3, April 2005.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fifth Edition)”, World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

9.2. Дополнительная литература

[NSC] John, W., Pentikousis, K., Agapiou, G., Jacob, E., Kind, M., Manzalini, A., Risso, F., Staessens, D., Steinert, R., and C. Meirosu, “Research directions in network service chaining”, 2013 IEEE SDN for Future Networks and Services (SDN4FNS), Trento, Italy, DOI 10.1109/SDN4FNS.2013.6702549, November 2013, <https://doi.org/10.1109/SDN4FNS.2013.6702549>.

[PERF-METRICS] IANA, “Performance Metrics”, <https://www.iana.org/assignments/performance-metrics>.

[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>.

[RFC5618] Morton, A. and K. Hedayat, “Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)”, RFC 5618, DOI 10.17487/RFC5618, August 2009, <https://www.rfc-editor.org/info/rfc5618>.

[RFC5938] Morton, A. and M. Chiba, “Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)”, RFC 5938, DOI 10.17487/RFC5938, August 2010, <https://www.rfc-editor.org/info/rfc5938>.

[RFC7312] Fabini, J. and A. Morton, “Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)”, RFC 7312, DOI 10.17487/RFC7312, August 2014, <https://www.rfc-editor.org/info/rfc7312>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, “Software-Defined Networking (SDN): Layers and Architecture Terminology”, RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, “PKCS #5: Password-Based Cryptography Specification Version 2.1”, RFC 8018, DOI 10.17487/RFC8018, January 2017, <https://www.rfc-editor.org/info/rfc8018>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

Приложение A. Подробные примеры моделей данных

В этом приложении представлены расширения примеров из раздела 6 с конфигурацией дополнительных полей, таких как параметры аутентификации, значения DSCP и т. п.

A.1. Control-Client

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <client>
         <admin-state>true</admin-state>
         <mode-preference-chain>
           <priority>0</priority>
           <mode>authenticated</mode>
         </mode-preference-chain>
         <mode-preference-chain>
           <priority>1</priority>
           <mode>unauthenticated</mode>
         </mode-preference-chain>
         <key-chain>
           <key-id>KeyClient1ToRouterA</key-id>
           <secret-key>c2VjcmV0MQ==</secret-key>
         </key-chain>
         <key-chain>
           <key-id>KeyForRouterB</key-id>
           <secret-key>c2VjcmV0Mg0K</secret-key>
         </key-chain>
         <ctrl-connection>
           <name>RouterA</name>
           <client-ip>203.0.113.1</client-ip>
           <server-ip>203.0.113.2</server-ip>
           <control-packet-dscp>32</control-packet-dscp>
           <key-id>KeyClient1ToRouterA</key-id>
           <test-session-request>
             <name>Test1</name>
             <sender-ip>203.0.113.3</sender-ip>
             <sender-udp-port>54000</sender-udp-port>
             <reflector-ip>203.0.113.4</reflector-ip>
             <reflector-udp-port>55000</reflector-udp-port>
             <padding-length>64</padding-length>
             <start-time>0</start-time>
           </test-session-request>
           <test-session-request>
             <name>Test2</name>
             <sender-ip>203.0.113.1</sender-ip>
             <sender-udp-port>54001</sender-udp-port>
             <reflector-ip>203.0.113.2</reflector-ip>
             <reflector-udp-port>55001</reflector-udp-port>
             <padding-length>128</padding-length>
             <start-time>0</start-time>
           </test-session-request>
         </ctrl-connection>
       </client>
     </twamp>
   </data>

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <client>
         <admin-state>true</admin-state>
         <mode-preference-chain>
           <priority>0</priority>
           <mode>authenticated</mode>
         </mode-preference-chain>
         <mode-preference-chain>
           <priority>1</priority>
           <mode>unauthenticated</mode>
         </mode-preference-chain>
         <key-chain>
           <key-id>KeyClient1ToRouterA</key-id>
           <secret-key>c2VjcmV0MQ==</secret-key>
         </key-chain>
         <key-chain>
           <key-id>KeyForRouterB</key-id>
           <secret-key>c2VjcmV0Mg0K</secret-key>
         </key-chain>
         <ctrl-connection>
           <name>RouterA</name>
           <client-ip>2001:db8:203:0:113::1</client-ip>
           <server-ip>2001:db8:203:0:113::2</server-ip>
           <control-packet-dscp>32</control-packet-dscp>
           <key-id>KeyClient1ToRouterA</key-id>
           <test-session-request>
             <name>Test1</name>
             <sender-ip>2001:db8:10:1:1::1</sender-ip>
             <sender-udp-port>54000</sender-udp-port>
             <reflector-ip>2001:db8:10:1:1::2</reflector-ip>
             <reflector-udp-port>55000</reflector-udp-port>
             <padding-length>64</padding-length>
             <start-time>0</start-time>
           </test-session-request>
           <test-session-request>
             <name>Test2</name>
             <sender-ip>2001:db8:203:0:113::1</sender-ip>
             <sender-udp-port>54001</sender-udp-port>
             <reflector-ip>2001:db8:203:0:113::2</reflector-ip>
             <reflector-udp-port>55001</reflector-udp-port>
             <padding-length>128</padding-length>
             <start-time>0</start-time>
           </test-session-request>
         </ctrl-connection>
       </client>
     </twamp>
   </data>

A.2. Сервер

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <server>
         <admin-state>true</admin-state>
         <servwait>1800</servwait>
         <control-packet-dscp>32</control-packet-dscp>
         <modes>authenticated unauthenticated</modes>
         <count>15</count>
         <key-chain>
           <key-id>KeyClient1ToRouterA</key-id>
           <secret-key>c2VjcmV0MQ==</secret-key>
         </key-chain>
         <key-chain>
           <key-id>KeyClient10ToRouterA</key-id>
           <secret-key>c2VjcmV0MTANCg==</secret-key>
         </key-chain>
         <ctrl-connection>
           <client-ip>203.0.113.1</client-ip>
           <client-tcp-port>16341</client-tcp-port>
           <server-ip>203.0.113.2</server-ip>
           <server-tcp-port>862</server-tcp-port>
           <control-packet-dscp>32</control-packet-dscp>
           <selected-mode>unauthenticated</selected-mode>
           <key-id>KeyClient1ToRouterA</key-id>
           <count>15</count>
         </ctrl-connection>
       </server>
     </twamp>
   </data>

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <server>
         <admin-state>true</admin-state>
         <servwait>1800</servwait>
         <control-packet-dscp>32</control-packet-dscp>
         <modes>authenticated unauthenticated</modes>
         <count>15</count>
         <key-chain>
           <key-id>KeyClient1ToRouterA</key-id>
           <secret-key>c2VjcmV0MQ==</secret-key>
         </key-chain>
         <key-chain>
           <key-id>KeyClient10ToRouterA</key-id>
           <secret-key>c2VjcmV0MTANCg==</secret-key>
         </key-chain>
         <ctrl-connection>
           <client-ip>2001:db8:203:0:113::1</client-ip>
           <client-tcp-port>16341</client-tcp-port>
           <server-ip>2001:db8:203:0:113::2</server-ip>
           <server-tcp-port>862</server-tcp-port>
           <control-packet-dscp>32</control-packet-dscp>
           <selected-mode>unauthenticated</selected-mode>
           <key-id>KeyClient1ToRouterA</key-id>
           <count>15</count>
         </ctrl-connection>
       </server>
     </twamp>
   </data>

A.3. Session-Sender

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <session-sender>
         <admin-state>true</admin-state>
         <test-session>
           <name>Test1</name>
           <ctrl-connection-name>RouterA</ctrl-connection-name>
           <fill-mode>zero</fill-mode>
           <number-of-packets>900</number-of-packets>
           <periodic-interval>1</periodic-interval>
           <sent-packets>2</sent-packets>
           <rcv-packets>2</rcv-packets>
           <last-sent-seq>1</last-sent-seq>
           <last-rcv-seq>1</last-rcv-seq>
         </test-session>
         <test-session>
           <name>Test2</name>
           <ctrl-connection-name>RouterA</ctrl-connection-name>
           <fill-mode>random</fill-mode>
           <number-of-packets>900</number-of-packets>
           <lambda>1</lambda>
           <max-interval>2</max-interval>
           <sent-packets>21</sent-packets>
           <rcv-packets>21</rcv-packets>
           <last-sent-seq>20</last-sent-seq>
           <last-rcv-seq>20</last-rcv-seq>
         </test-session>
       </session-sender>
     </twamp>
   </data>

A.4. Session-Reflector

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <session-reflector>
         <admin-state>true</admin-state>
         <test-session>
           <sender-ip>203.0.113.3</sender-ip>
           <sender-udp-port>54000</sender-udp-port>
           <reflector-ip>203.0.113.4</reflector-ip>
           <reflector-udp-port>55000</reflector-udp-port>
           <sid>1232</sid>
           <parent-connection-client-ip>203.0.113.1</parent-connection-\
   client-ip>
           <parent-connection-client-tcp-port>16341</parent-connection-\
   client-tcp-port>
           <parent-connection-server-ip>203.0.113.2</parent-connection-\
   server-ip>
           <parent-connection-server-tcp-port>862</parent-connection-se\
   rver-tcp-port>
           <test-packet-dscp>32</test-packet-dscp>
           <sent-packets>2</sent-packets>
           <rcv-packets>2</rcv-packets>
           <last-sent-seq>1</last-sent-seq>
           <last-rcv-seq>1</last-rcv-seq>
         </test-session>
         <test-session>
           <sender-ip>203.0.113.1</sender-ip>
           <sender-udp-port>54001</sender-udp-port>
           <reflector-ip>192.0.2.2</reflector-ip>
           <reflector-udp-port>55001</reflector-udp-port>
           <sid>178943</sid>
           <parent-connection-client-ip>203.0.113.1</parent-connection-\
   client-ip>
           <parent-connection-client-tcp-port>16341</parent-connection-\
   client-tcp-port>
           <parent-connection-server-ip>203.0.113.2</parent-connection-\
   server-ip>
           <parent-connection-server-tcp-port>862</parent-connection-se\
   rver-tcp-port>
           <test-packet-dscp>32</test-packet-dscp>
           <sent-packets>21</sent-packets>
           <rcv-packets>21</rcv-packets>
           <last-sent-seq>20</last-sent-seq>
           <last-rcv-seq>20</last-rcv-seq>
         </test-session>
       </session-reflector>
     </twamp>
   </data>

   <?xml version="1.0" encoding="utf-8"?>
   <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <twamp xmlns="urn:ietf:params:xml:ns:yang:ietf-twamp">
       <session-reflector>
         <admin-state>true</admin-state>
         <test-session>
           <sender-ip>2001:db8:10:1:1::1</sender-ip>
           <sender-udp-port>54000</sender-udp-port>
           <reflector-ip>2001:db8:10:1:1::2</reflector-ip>
           <reflector-udp-port>55000</reflector-udp-port>
           <sid>1232</sid>
           <parent-connection-client-ip>2001:db8:203:0:113::1</parent-c\
   onnection-client-ip>
           <parent-connection-client-tcp-port>16341</parent-connection-\
   client-tcp-port>
           <parent-connection-server-ip>2001:db8:203:0:113::2</parent-c\
   onnection-server-ip>
           <parent-connection-server-tcp-port>862</parent-connection-se\
   rver-tcp-port>
           <test-packet-dscp>32</test-packet-dscp>
           <sent-packets>2</sent-packets>
           <rcv-packets>2</rcv-packets>
           <last-sent-seq>1</last-sent-seq>
           <last-rcv-seq>1</last-rcv-seq>
         </test-session>
         <test-session>
           <sender-ip>2001:db8:203:0:113::1</sender-ip>
           <sender-udp-port>54001</sender-udp-port>
           <reflector-ip>2001:db8:192:68::2</reflector-ip>
           <reflector-udp-port>55001</reflector-udp-port>
           <sid>178943</sid>
           <parent-connection-client-ip>2001:db8:203:0:113::1</parent-c\
   onnection-client-ip>
           <parent-connection-client-tcp-port>16341</parent-connection-\
   client-tcp-port>
           <parent-connection-server-ip>2001:db8:203:0:113::2</parent-c\
   onnection-server-ip>
           <parent-connection-server-tcp-port>862</parent-connection-se\
   rver-tcp-port>
           <test-packet-dscp>32</test-packet-dscp>
           <sent-packets>21</sent-packets>
           <rcv-packets>21</rcv-packets>
           <last-sent-seq>20</last-sent-seq>
           <last-rcv-seq>20</last-rcv-seq>
         </test-session>
       </session-reflector>
     </twamp>
   </data>

Приложение B. Рабочие команды

Рабочие команды TWAMP могут выполняться программами или вручную, например через командный интерфейс (command-line interface или CLI).

В части программируемости YANG можно использовать для определения вызовов NETCONF Remote RPC, поэтому можно было бы определить операции TWAMP RPC для таких действий, как запуск и остановка управляющих соединений, тестовых сессий или их групп, очистки сохранённых результатов и т. п. Однако TWAMP [RFC5357] не описывает такие операции (см. также раздел 2 и соединения без меток на рисунке 1). В развёрнутых системах разные реализации TWAMP могут поддерживать отличающиеся наборы рабочих команд с разными ограничениями, поэтому данный документе оставляет за реализациями ответственность за определение моделей данных для рабочих команд.

Благодарности

Спасибо Fred Baker, Kevin D’Souza, Gregory Mirsky, Brian Trammell, Robert Sherman, Marius Georgescu за их подробные и конструктивные рецензии, комментарии и предложения по тексту документа.

Haoxing Shen внёс вклад в определение модуля YANG (раздел 5). Jan Lindblad и Ladislav Lhotka провели тщательный анализ модуля YANG и примеров из приложения A.

Kostas Pentikousis получил частичную поддержку в рамках исследовательского проекта FP7 UNIFY, финансируемого Европейской комиссией в рамках программы Seventh Framework (грант 619609). Выраженные здесь токи зрения принадлежат лишь авторам и Еврокомиссия не отвечает за любое использование сведений из этого документа.

Участник работы

Lianshu Zheng

Адреса авторов

Ruth Civil
Ciena Corporation
307 Legget Drive
Kanata ON K2K 3C8
Canada
Email: ruthcivil@gmail.com
URI: www.ciena.com
 
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
United States of America
Phone: +1 732 420 1571
Email: acmorton@att.com
 
Reshad Rahman
Canada
Email: reshad@yahoo.com
 
Mahesh Jethanandani
Xoriant Corporation
1248 Reamwood Avenue
Sunnyvale, CA 94089
United States of America
Email: mjethanandani@gmail.com
 
Kostas Pentikousis (editor)
Detecon
Winterfeldtstrasse 21
10781 Berlin
Germany
Email: kostas.pentikousis@detecon.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Denial-of-service – отказ в обслуживании.

Рубрика: RFC | Оставить комментарий

RFC 9067 A YANG Data Model for Routing Policy

image_print
Internet Engineering Task Force (IETF)                             Y. Qu
Request for Comments: 9067                                     Futurewei
Category: Standards Track                                    J. Tantsura
ISSN: 2070-1721                                                Microsoft
                                                               A. Lindem
                                                                   Cisco
                                                                  X. Liu
                                                          Volta Networks
                                                            October 2021

A YANG Data Model for Routing Policy

Модель данных YANG для политики маршрутизации

PDF

Аннотация

Этот документ определяет модель данных YANG для настройки и управления политикой маршрутизации независимо от его производителя (vendor-neutral). Модель обеспечивает базовую схему политики маршрутизации, которую можно расширить для конкретных протоколов маршрутизации с использованием механизма YANG augment.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9067.

Авторские права

Авторские права (Copyright (c) 2021) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML.

1. Введение

Документ описывает модель данных YANG [RFC7950] для настройки политики маршрутизации на основе опыта работы сетей различных сервис-провайдеров. Модель не привязана к оборудованию, чтобы позволить операторам управлять конфигурацией политики в средах с маршрутизаторами разных производителей.

Модули YANG в документе соответствуют архитектуре хранилищ данных управления (NMDA) [RFC8342].

1.1. Цели и подход

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

Несмотря на различие в деталях выражения политики в средах разных производителей, модель отражает наблюдение, что относительно простой подход «условие-действие» легко сопоставить с несколькими имеющимися реализациями производителей, а также даёт операторам знакомый и прямой способ выражения политики. Побочным эффектом этого подхода является исключение других методов из рассмотрения.

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

2. Терминология и обозначения

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Routing policy – политика маршрутизации

Политика маршрутизации определяет импорт, экспорт, изменение и анонсирование между экземплярами протоколов маршрутизации или в одном экземпляре протокола.

Policy chain – цепочка политики

Последовательность определений политики. На цепочку могут указывать ссылки из другого контекста.

Policy statement – оператор политики

Оператор политики состоит из набора условий и действий (любое из них может быть пустым).

Ниже перечислены термины, определённые в [RFC8342]:

  • client – клиент;

  • server – сервер;

  • configuration – конфигурация;

  • system state – состояние системы;

  • operational state – рабочее состояние;

  • intended configuration – предполагаемая конфигурация.

Ряд терминов определён в [RFC7950]:

  • action – действие;

  • augment – дополнение;

  • container – контейнер;

  • container with presence – контейнер присутствия;

  • data model – модель данных;

  • data node – узел данных;

  • feature – свойство, функция;

  • leaf – лист;

  • list – список;

  • mandatory node – обязательный узел;

  • module – модуль;

  • schema tree – дерево схемы;

  • RPC (Remote Procedure Call) operation – вызов удалённой процедуры.

2.1. Диаграммы деревьев

Диаграммы деревьев в этом документе используют обозначения, заданные в [RFC8340].

2.2. Префиксы в именах узлов данных

В этом документе имена узлов данных, действий и других объектов модели данных используются без префиксов, если из контекста очевидно, в каком модуле YANG они определены. В остальных случаях имена указываются со стандартным префиксом соответствующего модуля YANG (Таблица 1).

Таблица 1. Префиксы и соответствующие модули YANG.

Префикс

Модуль YANG

Документ

if

ietf-interfaces

[RFC8343]

rt

ietf-routing

[RFC8349]

yang

ietf-yang-types

[RFC6991]

inet

ietf-inet-types

[RFC6991]

3. Обзор модели

Модуль политики маршрутизации состоит из 3 частей, кратко описанных ниже.

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

  • Структура, позволяющая протоколам маршрутизации добавлять свои условия и действия с помощью дополнений YANG (augment). Имеется пример для протокола BGP [RFC4271] в нейтральной по отношению к производителям модели данных BGP [IDR-BGP-MODEL]. В Приложении A приведён пример расширения для политики BGP. Приложение не является нормативным, поскольку модель для BGP ещё не завершена.

  • Пригодная для многократного применения группировка для присоединения правил импорта и экспорта в контексте настройки маршрутизации для разных протоколов, экземпляров виртуальной маршрутизации и пересылки (Virtual Routing and Forwarding или VRF) и т. п. Это также позволяет создавать цепочки политики и выражать принятое по умолчанию поведение политики. В этом документе цепочки и последовательности политики – это последовательности определений, применяемые в определённом порядке (см. раздел 4).

В модуле используются стандартные типы Internet, такие как адреса IP, номера автономных систем и т. п., определённые в RFC 6991 [RFC6991].

4. Выражение политики маршрута

Политика выражается последовательностью определений верхнего уровня, каждое из которых является последовательностью операторов политики. Операторы состоят из простых кортежей «условие-действие». Условия могут включать несколько операторов сопоставления или сравнения, а действия – набор изменений атрибутов маршрута или указание финального восприятия или отклонения маршрута. Структура показана на рисунке.

     +--rw routing-policy
        +--rw policy-definitions
           +--ro match-modified-attributes?   boolean
           +--rw policy-definition* [name]
              +--rw name          string
              +--rw statements
                 +--rw statement* [name]
                    +--rw name          string
                    +--rw conditions
                    |     ...
                    +--rw actions
                          ...

4.1. Наборы для сопоставления

Модель представляет коллекцию базовых наборов, которые могут применяться в условиях политики для сопоставлений. Эти наборы подходят для выбора маршрутов из разных протоколов маршрутизации. Их можно дополнить связанными с протоколами моделями, имеющими свои наборы. Заданные наборы показаны ниже.

prefix sets – наборы префиксов

Каждый набор определяет множество префиксов IP с диапазоном или точным значением маски сети.

neighbor sets – наборы соседей

Набор соседних узлов с их адресами IP. Этот набор служит для выбора маршрутов по анонсирующих их соседям.

tag sets – наборы тегов

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

Структура модели для заданных наборов показана ниже.

       +--rw routing-policy
          +--rw defined-sets
          |  +--rw prefix-sets
          |  |  +--rw prefix-set* [name]
          |  |     +--rw name        string
          |  |     +--rw mode?       enumeration
          |  |     +--rw prefixes
          |  |        +--rw prefix-list* [ip-prefix mask-length-lower
          |  |                            mask-length-upper]
          |  |           +--rw ip-prefix           inet:ip-prefix
          |  |           +--rw mask-length-lower    uint8
          |  |           +--rw mask-length-upper    uint8
          |  +--rw neighbor-sets
          |  |  +--rw neighbor-set* [name]
          |  |     +--rw name       string
          |  |     +--rw address*   inet:ip-address
          |  +--rw tag-sets
          |     +--rw tag-set* [name]
          |        +--rw name         string
          |        +--rw tag-value*   tag-type

4.2. Условия политики

Операторы политики состоят из набора условий и действий (любой из них может быть пустым). Условия задают сопоставление атрибутов маршрута с заданным набором (например, набором префиксов) или сравнение с конкретным значением. Сопоставление можно изменить с помощью опций (match-set-options):

all

значение true возвращается при соответствии всех элементов набора;

any

значение true возвращается при соответствии любого элементов набора;

invert

значение true возвращается, если ни один элемент набора не соответствует.

Не все опции подходят для сопоставления с каждым определенным набором (например, сопоставление all не имеет смысла для набора префиксов). Когда это приемлемо, в модели применяется ограниченный набор опций соответствия.

В сравнениях также могут применяться эти опции, например для равенства или неравенства.

Хотя большинство условий политики будут добавлять отдельные модели для протоколов маршрутизации путём дополнений, эта модель политики маршрутизации включает несколько базовых сопоставлений и возможность проверить, какой из протоколов или механизмов установил маршрут (например, BGP, IGP, статика и пр.). Включённые в модель условия показаны ниже.

     +--rw routing-policy
        +--rw policy-definitions
           +--rw policy-definition* [name]
              +--rw name          string
              +--rw statements
                 +--rw statement* [name]
                    +--rw conditions
                    |  +--rw call-policy?
                    |  +--rw source-protocol?
                    |  +--rw match-interface
                    |  |  +--rw interface?
                    |  +--rw match-prefix-set
                    |  |  +--rw prefix-set?
                    |  |  +--rw match-set-options?
                    |  +--rw match-neighbor-set
                    |  |  +--rw neighbor-set?
                    |  +--rw match-tag-set
                    |  |  +--rw tag-set?
                    |  |  +--rw match-set-options?
                    |  +--rw match-route-type
                    |     +--rw route-type*

4.3. Действия политики

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

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

     +--rw routing-policy
        +--rw policy-definitions
           +--rw policy-definition* [name]
              +--rw statements
                 +--rw statement* [name]
                    +--rw actions
                       +--rw policy-result?   policy-result-type
                       +--rw set-metric
                       |  +--rw metric-modification?
                       |  |         metric-modification-type
                       |  +--rw metric?                 uint32
                       +--rw set-metric-type
                       |  +--rw metric-type?   identityref
                       +--rw set-route-level
                       |  +--rw route-level?   identityref
                       +--rw set-route-preference?      uint16
                       +--rw set-tag?               tag-type
                       +--rw set-application-tag?   tag-type

4.4. Вложенные правила

Поддерживаются «подпрограммы» политики (вложенные правила), позволяющие задавать условные ссылки на другие определения с использованием конфигурации вызова правил (call-policy). Вызванные правила применяют свои условия и действия до возврата в вызвавший оператор, после чего продолжается оценка (исполнение) политики. Результат вызова влияет на исполнение вызывающего правила. Если вызванное правило приводит к принятию маршрута (accept-route), «подпрограмма» возвращает вызвавшему правилу логическое значение true. Для вызывающей политики это эквивалентно оператору условия с результатом true, поэтому вызывающая сторона продолжает исполнение политики (см. раздел 5). Отметим, что вызываемое правило может менять атрибуты маршрута в своих операторах действий. Действие reject-route возвращает значение false с соответствующим влиянием на вызвавшую политику. При достижении последнего оператора «подпрограммы» применяется принятое по умолчанию финальное действие (т. е. false для reject-route). Поэтому «подпрограмма» не может явно принять или отклонить маршрут, а вместо этого возвращает логическое значение true для accept-route и false для reject-route. Принятие или отклонение маршрута полностью определяет политика верхнего уровня.

Отметим, что вызываемая политика сама может вызывать другие правила (реализация может ограничивать это). Модель не задаёт глубину вложенности, поскольку она может меняться в реализациях, например, реализация может поддерживать лишь один уровень рекурсии. Как в любой политике политике маршрутизации, следует соблюдать осторожность при вызовах «подпрограмм», чтобы возвращаемое ими значение обеспечивало нужное поведение. Вложенные правила удобны во многих вариантах политики маршрутизации, но создавать правила с глубокой рекурсией (например, больше 2-3) не рекомендуется. Кроме того, реализации должны выполнять проверку отсутствия рекурсии между вложенными правилами маршрутизации.

5. Исполнение политики

Исполнение (оценка) каждого определения политики выполняется путём выполнения отдельных операторов в порядке из указания. Когда все условия в операторе политики соблюдены, исполняются соответствующие операторы действий. Если действие включает accept-route или reject-route, выполнение текущего правила прекращается с переходом к следующему правилу. Если в цепочке политики множество правил, последующие правила цепочки в этом случае не исполняются. Цепочки представляют собой последовательности определений правил, (см. раздел 4).

Если условия не соблюдены, происходит переход к следующему оператору политики. Если не выполняется ни одно из условий оператора политики, исполнение текущего определения прекращается с переходом к следующему определению в цепочке. По достижении конца цепочки правил применяется заданное по умолчанию действие (reject-route, если в цепочке явно не задано иное действие).

Использование предварительных атрибутов для проверки условий в операторе политики зависит от принятого реализацией значения листа match-modified-attributes (сопоставление изменённых атрибутов). Если этот лист имеет значение false и действие меняет атрибуты маршрута, эти изменения не учитываются в операторах условий. Если же match-modified-attributes = true и действие меняет зависящие от приложения атрибуты, изменённые значения участвуют в проверке условий.

6. Применение политики маршрутизации

Политика маршрутизации применяется путём определения и присоединения цепочек правил в разных контекстах маршрутизации. Цепочки правил являются последовательностями определений (см. раздел 4), на которые можно указывать из разных контекстов. Например, цепочка правил может быть связана с протоколом маршрутизации и применяться для управления его взаимодействием с протокольными партнёрами или локальной базой маршрутной информации. С цепочкой правил связано направление (импорт или экспорт) по отношению к ссылающемуся на цепочку контексту.

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

         +--rw apply-policy
         |  +--rw import-policy*
         |  +--rw default-import-policy?   default-policy-type
         |  +--rw export-policy*
         |  +--rw default-export-policy?   default-policy-type

Принятая по умолчанию политика в этой модели задаёт отклонение (reject) маршрута для импорта и экспорта.

7. Модуль и дерево YANG

7.1. Дерево модели политики маршрутизации

Дерево модели политики маршрутизации показано ниже.

   module: ietf-routing-policy
     +--rw routing-policy
        +--rw defined-sets
        |  +--rw prefix-sets
        |  |  +--rw prefix-set* [name mode]
        |  |     +--rw name        string
        |  |     +--rw mode        enumeration
        |  |     +--rw prefixes
        |  |        +--rw prefix-list* [ip-prefix mask-length-lower
        |  |                            mask-length-upper]
        |  |           +--rw ip-prefix            inet:ip-prefix
        |  |           +--rw mask-length-lower    uint8
        |  |           +--rw mask-length-upper    uint8
        |  +--rw neighbor-sets
        |  |  +--rw neighbor-set* [name]
        |  |     +--rw name       string
        |  |     +--rw address*   inet:ip-address
        |  +--rw tag-sets
        |     +--rw tag-set* [name]
        |        +--rw name         string
        |        +--rw tag-value*   tag-type
        +--rw policy-definitions
           +--ro match-modified-attributes?   boolean
           +--rw policy-definition* [name]
              +--rw name          string
              +--rw statements
                 +--rw statement* [name]
                    +--rw name          string
                    +--rw conditions
                    |  +--rw call-policy?       -> ../../../../../..
                    |                           /policy-definitions
                    |                           /policy-definition/name
                    |  +--rw source-protocol?      identityref
                    |  +--rw match-interface
                    |  |  +--rw interface?      if:interface-ref
                    |  +--rw match-prefix-set
                    |  |  +--rw prefix-set?     -> ../../../../../../..
                    |  |                        /defined-sets
                    |  |                        /prefix-sets
                    |  |                        /prefix-set/name
                    |  |  +--rw match-set-options?
                    |  |                        match-set-options-type
                    |  +--rw match-neighbor-set
                    |  |  +--rw neighbor-set?   -> ../../../../../../..
                    |  |                        /defined-sets
                    |  |                        /neighbor-sets
                    |  |                        /neighbor-set/name
                    |  +--rw match-tag-set
                    |  |  +--rw tag-set?        -> ../../../../../../..
                    |  |                        /defined-sets/tag-sets
                    |  |                        /tag-set/name
                    |  |  +--rw match-set-options?
                    |  |                        match-set-options-type
                    |  +--rw match-route-type
                    |     +--rw route-type*     identityref
                    +--rw actions
                       +--rw policy-result?         policy-result-type
                       +--rw set-metric
                       |  +--rw metric-modification?
                       |                        metric-modification-type
                       |  +--rw metric?                uint32
                       +--rw set-metric-type
                       |  +--rw metric-type?   identityref
                       +--rw set-route-level
                       |  +--rw route-level?   identityref
                       +--rw set-route-preference?        uint16
                       +--rw set-tag?               tag-type
                       +--rw set-application-tag?   tag-type

7.2. Модель политики маршрутизации

В тексте документа нет ссылок на упоминаемые в модуле ietf-routing-policy.yang [RFC2328], [RFC3101], [RFC5130], [RFC5302], [RFC6991], [RFC8343].

   <CODE BEGINS> file "ietf-routing-policy@2021-10-11.yang"
   module ietf-routing-policy {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
     prefix rt-pol;

     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-interfaces {
       prefix if;
       reference
         "RFC 8343: A YANG Data Model for Interface
                    Management";
     }
     import ietf-routing {
       prefix rt;
       reference
         "RFC 8349: A YANG Data Model for Routing
                    Management (NMDA Version)";
     }

     organization
       "IETF RTGWG - Routing Area Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/rtgwg/> 
        WG List:  <mailto: rtgwg@ietf.org> 

        Editors:  Yingzhen Qu
                  <mailto: yingzhen.qu@futurewei.com> 
                  Jeff Tantsura
                  <mailto: jefftant.ietf@gmail.com> 
                  Acee Lindem
                  <mailto: acee@cisco.com> 
                  Xufeng Liu
                  <mailto: xufeng.liu.ietf@gmail.com>"; 
     description
       "Этот модуль описывает модель данных YANG для настройки политики
        маршрутизации. Он включает ограниченный набор параметров 
        конфигурации, доступных в реализациях разных производителей, но
        поддерживает широко применяемые конструкции для управления 
        импортом, экспортом, изменением и анонсированием маршрутов в
        одном или разных экземплярах протоколов маршрутизации. Модуль
        предназначен для использования с модулями настройки протоколов
        маршрутизации, например BGP), определёнными в других моделях.

        Этот модуль YANG соответствует архитектуре хранилищ управления
        сетью (NMDA), определённой в RFC 8342.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО, 
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с 
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

        Авторские права (Copyright (c) 2021) принадлежат IETF Trust и
        лицам, указанным как авторы. Все права защищены.

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 9067, где правовые
        аспекты приведены более полно.";

     reference
       "RFC 9067: A YANG Data Model for Routing Policy.";

     revision 2021-10-11 {
       description
         "Initial revision.";
       reference
         "RFC 9067: A YANG Data Model for Routing Policy.";
     }

     /* Отождествления */

     identity metric-type {
       description
         "Базовое отождествление для типов метрики маршрутов.";
     }

     identity ospf-type-1-metric {
       base metric-type;
       description
         "Указывает типы внешней метрики OSPF типа 1. Применимо лишь 
          к маршрутам OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     identity ospf-type-2-metric {
       base metric-type;
       description
         "Указывает типы внешней метрики OSPF типа 2. Применимо лишь 
          к маршрутам OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     identity isis-internal-metric {
       base metric-type;
       description
         "Указывает типы внутренней метрики IS-IS. Применимо лишь
          к маршрутам IS-IS.";
       reference
         "RFC 5302: Domain-Wide Prefix Distribution with
          Two-Level IS-IS";
     }

     identity isis-external-metric {
       base metric-type;
       description
         "Указывает типы внешней метрики IS-IS. Применимо лишь
          к маршрутам IS-IS.";
       reference
         "RFC 5302: Domain-Wide Prefix Distribution with
          Two-Level IS-IS";
     }

     identity route-level {
       description
         "Базовое отождествление для уровня импорта маршрута.";
     }

     identity ospf-normal {
       base route-level;
       description
         "Отождествление импорта OSPF в обычные области. Применяется
          лишь к маршрутам, импортируемым в OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     identity ospf-nssa-only {
       base route-level;
       description
         "Отождествление импорта в области OSPF Not-So-Stubby (NSSA). 
          Применяется лишь к маршрутам, импортируемым в OSPF.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     identity ospf-normal-nssa {
       base route-level;
       description
         "Отождествление импорта в области OSPF и области NSSA. 
          Применяется лишь к маршрутам, импортируемым в OSPF.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     identity isis-level-1 {
       base route-level;
       description
         "Отождествление импорта в области IS-IS Level 1. Применяется лишь
          к маршрутам, импортируемым в протокол IS-IS.";
       reference
         "RFC 5302: Domain-Wide Prefix Distribution with
          Two-Level IS-IS";
     }

     identity isis-level-2 {
       base route-level;
       description
         "Отождествление импорта в области IS-IS Level 2. Применяется лишь
          к маршрутам, импортируемым в протокол IS-IS.";
       reference
         "RFC 5302: Domain-Wide Prefix Distribution with
          Two-Level IS-IS";
     }

     identity isis-level-1-2 {
       base route-level;
       description
         "Отождествление импорта в области IS-IS Level 1 и Level 2. Применяется 
          лишь к маршрутам, импортируемым в протокол IS-IS.";
       reference
         "RFC 5302: Domain-Wide Prefix Distribution with
          Two-Level IS-IS";
     }

     identity proto-route-type {
       description
         "Базовое отождествление типа маршрута внутри протокола.";
     }

     identity isis-level-1-type {
       base proto-route-type;
       description
         "Отождествление маршрута IS-IS Level 1. Применяется лишь к маршрутам
          IS-IS.";
       reference
         "RFC 5302: Domain-Wide Prefix Distribution with
          Two-Level IS-IS";
     }

     identity isis-level-2-type {
       base proto-route-type;
       description
         "Отождествление маршрута IS-IS Level 2. Применяется лишь к маршрутам
          IS-IS.";
       reference
         "RFC 5302: Domain-Wide Prefix Distribution with
          Two-Level IS-IS";
     }

     identity ospf-internal-type {
       base proto-route-type;
       description
         "Отождествление маршрута внутри или между областями OSPF.
          Применяется лишь к маршрутам OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     identity ospf-external-type {
       base proto-route-type;
       description
         "Отождествление внешнего маршрута OSPF типа 1 или 2.
          Применяется лишь к маршрутам OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     identity ospf-external-t1-type {
       base ospf-external-type;
       description
         "Отождествление внешнего маршрута OSPF типа 1.
          Применяется лишь к маршрутам OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     identity ospf-external-t2-type {
       base ospf-external-type;
       description
         "Отождествление внешнего маршрута OSPF типа 2.
          Применяется лишь к маршрутам OSPF.";
       reference
         "RFC 2328: OSPF Version 2";
     }

     identity ospf-nssa-type {
       base proto-route-type;
       description
         "Отождествление маршрута OSPF NSSA типа 1 или 2.
          Применяется лишь к маршрутам OSPF.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     identity ospf-nssa-t1-type {
       base ospf-nssa-type;
       description
         "Отождествление маршрута OSPF NSSA типа 1.
          Применяется лишь к маршрутам OSPF.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     identity ospf-nssa-t2-type {
       base ospf-nssa-type;
       description
         "Отождествление маршрута OSPF NSSA типа 2.
          Применяется лишь к маршрутам OSPF.";
       reference
         "RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
     }

     identity bgp-internal {
       base proto-route-type;
       description
         "Отождествление маршрутов, полученных от внутреннего BGP (IBGP).
          Применяется лишь к маршрутам BGP.";
       reference
         "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
     }

     identity bgp-external {
       base proto-route-type;
       description
         "Отождествление маршрутов, полученных от внешнего BGP (EBGP).
          Применяется лишь к маршрутам BGP.";
       reference
         "RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
     }


     /* Определения типов */

     typedef default-policy-type {
       type enumeration {
         enum accept-route {
           description
             "Принятое по умолчанию правило восприятия маршрута.";
         }
         enum reject-route {
           description
             "Принятое по умолчанию правило отклонения маршрута.";
         }
       }
       description
         "Тип служит для указания финального решения по маршруту
          в цепочке правил. Применяется в принятых по умолчанию
          правилах импорта и экспорта.";
     }

     typedef policy-result-type {
       type enumeration {
         enum accept-route {
           description
             "Правило для восприятия маршрута.";
         }
         enum reject-route {
           description
             "Правило для отклонения маршрута.";
         }
       }
       description
         "Тип служит для указания финального решения по маршруту
          в цепочке правил.";
     }

     typedef tag-type {
       type union {
         type uint32;
         type yang:hex-string;
       }
       description
         "Тип для выражения тегов маршрутов в локальной системе, 
          включая IS-IS и OSPF. Может быть десятичным или 
          шестнадцатеричным целым числом.";
       reference
         "RFC 2328: OSPF Version 2
          RFC 5130: A Policy Control Mechanism in IS-IS Using
                    Administrative Tags";
     }

     typedef match-set-options-type {
       type enumeration {
         enum any {
           description
             "Имеет значение true, если заданное значение совпадает
              с любым элементом определённого множества.";
         }
         enum all {
           description
             "Имеет значение true, если заданное значение совпадает
              со всеми элементами определённого множества.";
         }
         enum invert {
           description
             "Имеет значение true, если заданное значение не совпадает
              ни с одним элементом определённого множества.";
         }
       }
       default "any";
       description
         "Опции, управляющие поведением оператора match. По умолчанию 
          принято any, т. е. совпадение с любым элементом множества.";
     }

     typedef metric-modification-type {
       type enumeration {
         enum set-metric {
           description
             "Устанавливает конкретное значение метрики.";
         }
         enum add-metric {
           description
             "Добавляет указанное значение к имеющейся метике. При 
              переполнении устанавливается максимальное значение (0xffffffff)";
         }
         enum subtract-metric {
           description
             "Отнимает указанное значение от имеющейся метики. При
              получении отрицательного результата устанавливается 0.";
         }
       }
       description
         "Тип служит для установки нужного значения метрики.";
     }

     /* Группировки */

     grouping prefix {
       description
         "Конфигурационные данные для определения префиксов.

          Комбинация mask-length-lower и mask-length-upper
          задаёт диапазон размеров масок или одно значение, если
          mask-length-lower и mask-length-upper совпадают.

          Пример: диапазон 192.0.2.0/24 - 192.0.2.0/26 будет
          выражаться как prefix: 192.0.2.0/24,
                         mask-length-lower=24,
                         mask-length-upper=26

          Пример: 192.0.2.0/24 (точное совпадение) будет
          выражаться как prefix: 192.0.2.0/24,
                         mask-length-lower=24,
                         mask-length-upper=24

          Пример: диапазон 2001:DB8::/32 - 2001:DB8::/64 будет
          выражаться как prefix: 2001:DB8::/32,
                         mask-length-lower=32,
                         mask-length-upper=64";
       leaf ip-prefix {
         type inet:ip-prefix;
         mandatory true;
         description
           "Префикс IP, представленный как номер сети IPv6 или IPv4,
            за которым следует размер префикса через символ дробной
            черты. Все элементы prefix-set ДОЛЖНЫ относиться к тому 
            же семейству адресов, что и режим prefix-set.";
       }
       leaf mask-length-lower {
         type uint8 {
           range "0..128";
         }
         description
           "Нижняя граница размера маски. НЕДОПУСТИМЫ значения меньше
            размера prefix, заданного в ip-prefix.";
       }
       leaf mask-length-upper {
         type uint8 {
           range "1..128";
         }
         must '../mask-length-upper >= ../mask-length-lower' {
           error-message "The upper bound MUST NOT be less "
                       + "than lower bound.";
         }
         description
           "Верхняя граница размера маски. НЕДОПУСТИМЫ значения меньше
            нижней границы.";
       }
     }

     grouping match-set-options-group {
       description
         "Группировка опций, относящихся к сопоставлению с конкретным
          множеством.";
       leaf match-set-options {
         type match-set-options-type;
         description
           "Необязательный параметр, задающий поведение операции 
            сопоставления.";
       }
     }

     grouping match-set-options-restricted-group {
       description
         "Группировка для ограниченного набора модификаторов операции
          сопоставления.";
       leaf match-set-options {
         type match-set-options-type {
           enum any {
             description
               "Имеет значение true, если заданное значение совпадает
                с любым элементом определённого множества.";
           }
           enum invert {
             description
               "Имеет значение true, если заданное значение не совпадает
                ни с одним элементом определённого множества.";
           }
         }
         description
           "Необязательные параметры, управляющие поведением операции 
            сопоставления. Этот лист поддерживает лишь опции 
            any и invert, но не поддерживает all.";
       }
     }

     grouping apply-policy-group {
       description
         "Контейнер верхнего уровня для применения политики маршрутизации. 
          Группировка предназначена для использования в моделях маршрутизации.";
       container apply-policy {
         description
           "Опорная точка для политики маршрутизации в модели. Правила импорта
            и экспорта применяются к локальной таблице маршрутизации, т. е.
            export (передача) и import (приём) в зависимости от контекста.";
         leaf-list import-policy {
           type leafref {
             path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
                + "rt-pol:policy-definition/rt-pol:name";
             require-instance true;
           }
           ordered-by user;
           description
             "Список имён правил в порядке применения при получении 
              распространяемых маршрутов от другого протокола маршрутизации
              или обновлении маршрутизации в текущем контексте, например,
              для текущей группы партнёров, соседа, семейства адресов и т. п.";
         }
         leaf default-import-policy {
           type default-policy-type;
           default "reject-route";
           description
             "Явная установка принятой по умолчанию политики, если не выполнено
              определение в цепочке правил импорта.";
         }
         leaf-list export-policy {
           type leafref {
             path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
                + "rt-pol:policy-definition/rt-pol:name";
             require-instance true;
           }
           ordered-by user;
           description
             "Список имён правил в порядке применения при распространении
              маршрутов от одного протокола маршрутизации к другому или 
              передаче маршрутного обновления в текущем контексте, например,
              для текущей группы партнёров, соседа, семейства адресов и т. п.";
         }
         leaf default-export-policy {
           type default-policy-type;
           default "reject-route";
           description
             "Явная установка принятой по умолчанию политики, если не выполнено
              определение в цепочке правил экспорта.";
         }
       }
     }
     container routing-policy {
       description
         "Контейнер верхнего уровня для всей политики маршрутизации.";
       container defined-sets {
         description
           "Предопределённый набор атрибутов, используемых в операторах 
            сопоставления.";
         container prefix-sets {
           description
             "Определения данных для списка префиксов IPv4 или IPv6, 
              сопоставляемых как часть политики.";
           list prefix-set {
             key "name mode";
             description
               "Список определённых наборов префиксов";
             leaf name {
               type string;
               description
                 "Имя набора префиксов, используемое как метка для указания
                  набора в условиях сопоставления.";
             }
             leaf mode {
               type enumeration {
                 enum ipv4 {
                   description
                     "Набор префиксов IPv4.";
                 }
                 enum ipv6 {
                   description
                     "набор префиксов IPv6.";
                 }
               }
               description
                 "Указывает режим набора префиксов в части присутствия
                  семейств адресов (IPv4 или IPv6). Режим служит
                  указанием типа, к которому ДОЛЖНЫ относиться все
                  префиксы. Устройство ДОЛЖНО проверять все префиксы и
                  отвергать конфигурацию в случае несоответствия.";
             }
             container prefixes {
               description
                 "Контейнер для списка префиксов в политике. Поскольку
                  для отдельных префиксов нет уникальных действий, 
                  порядок сопоставления префиксов в prefix-list не
                  влияет на результат и определяется реализацией. Данное
                  условие prefix-set считается выполненным, если префикс
                  на входе соответствует любому из префиксов в prefix-set.";
               list prefix-list {
                 key "ip-prefix mask-length-lower mask-length-upper";
                 description
                   "Список префиксов в prefix set.";
                 uses prefix;
               }
             }
           }
         }
         container neighbor-sets {
           description
             "Определение данных для списка соседей IPv4 или IPv6,
              которые могут сопоставляться в политике маршрутизации.";
           list neighbor-set {
             key "name";
             description
               "Список наборов соседей для применения в правилах.";
             leaf name {
               type string;
               description
                 "Имя набора соседей, служащее меткой для указания в
                  сопоставлениях.";
             }
             leaf-list address {
               type inet:ip-address;
               description
                 "Список адресов IP для набора соседей.";
             }
           }
         }
         container tag-sets {
           description
             "Определение данных для списка тегов, которые могут 
              сопоставляться в политике.";
           list tag-set {
             key "name";
             description
               "Список определений набора тегов.";
             leaf name {
               type string;
               description
                 "Имя набора тегов, служащее меткой для указания в
                  сопоставлениях.";
             }
             leaf-list tag-value {
               type tag-type;
               description
                 "Значение элемента набора тегов.";
             }
           }
         }
       }
       container policy-definitions {
         description
           "Внешний контейнер для списка определений верхнего уровня 
            в политике.";
         leaf match-modified-attributes {
           type boolean;
           config false;

           description
             "Логическое значение, задающее сопоставление с фактическими
              атрибутами маршрута или атрибутами, изменёнными 
              предшествующими сопоставлению операторами.";
         }
         list policy-definition {
           key "name";
           description
             "Список определений верхнего уровня с уникальными именами
              (ключ). Предполагается, что эти определения будут указываться
              (по имени) в цепочках правил, заданных в операторах импорта
              или экспорта.";
           leaf name {
             type string;
             description
               "Имя определения верхнего уровня, применяемое для ссылки 
                на него.";
           }
           container statements {
             description
               "Внешний (включающий) контейнер для операторов политики.";
             list statement {
               key "name";
               ordered-by user;
               description
                 "Операторы политики группируют условия и действия внутри
                  определения политики. Они выполняются в порядке указания.";
               leaf name {
                 type string;
                 description
                   "Имя оператора политики.";
               }
               container conditions {
                 description
                   "Условный оператор для текущего оператора политики.";
                 leaf call-policy {
                   type leafref {
                     path "../../../../../../"
                        + "rt-pol:policy-definitions/"
                        + "rt-pol:policy-definition/rt-pol:name";
                     require-instance true;
                   }
                   description
                     "Применяет операторы из указанного определения политики
                      и возвращает управление текущему оператору. Вызываемое 
                      правило может само вызывать другие правила (реализация
                      может ограничивать это). Это предназначено для поддержки
                      «подпрограмм» политики. Вызываемому правилу СЛЕДУЕТ
                      включать явное или принятое по умолчанию финальное
                      решение для маршрута, возвращающее значение true
                      (accept-route) или false (reject-route). В противном
                      случае поведение может быть неоднозначным. Вызывающему
                      правилу НЕДОПУСТИМО быть вызванным ранее без возврата
                      (т. е. рекурсия не разрешается).";
                 }
                 leaf source-protocol {
                   type identityref {
                     base rt:control-plane-protocol;
                   }
                   description
                     "Условие для проверки протокола (метода), применяемого для
                      установки маршрута в локальной таблице маршрутизации.";
                 }
                 container match-interface {
                   leaf interface {
                     type if:interface-ref;
                     description
                       "Ссылка на базовый интерфейс.";
                   }
                   description
                     "Контейнер для условий сопоставления интерфейса.";
                 }
                 container match-prefix-set {
                   leaf prefix-set {
                     type leafref {
                       path "../../../../../../../defined-sets/"
                          + "prefix-sets/prefix-set/name";
                     }
                     description
                       "Ссылка на заданный набор префиксов.";
                   }
                   uses match-set-options-restricted-group;
                   description
                     "Сопоставление указанного набора префиксов в 
                      соответствии с логикой листа match-set-options.";
                 }
                 container match-neighbor-set {
                   leaf neighbor-set {
                     type leafref {
                       path "../../../../../../../defined-sets/"
                          + "neighbor-sets/neighbor-set/name";
                       require-instance true;
                     }
                     description
                       "Ссылка на заданный набор соседей.";
                   }
                   description
                     "Сопоставление с указанным набором соседей.";
                 }
                 container match-tag-set {
                   leaf tag-set {
                     type leafref {
                       path "../../../../../../../defined-sets/"
                          + "tag-sets/tag-set/name";
                       require-instance true;
                     }
                     description
                       "Ссылка на заданный набор тегов.";
                   }
                   uses match-set-options-group;
                   description
                     "Сопоставление указанного набора префиксов в 
                      соответствии с логикой листа match-set-options.";
                 }
                 container match-route-type {
                   description
                     "Контейнер, обеспечивающий условие сопоставления
                      route-type";
                   leaf-list route-type {
                     type identityref {
                       base proto-route-type;
                     }
                     description
                       "Условие для сопоставления зависящего от протокола 
                        типа маршрута. Обычно это применяется при импорте
                        маршрутов для выбора маршрутов или установки 
                        зависящих от протокола атрибутов по типу маршрута.";
                   }
                 }
               }
               container actions {
                 description
                   "Top-level container for policy action
                    statements.";
                 leaf policy-result {
                   type policy-result-type;
                   description
                     "Выбор финального решения для маршрута - восприятие
                      (accept) или отклонение (reject).";
                 }
                 container set-metric {
                   leaf metric-modification {
                     type metric-modification-type;
                     description
                       "Указывает, как изменить метрику.";
                   }
                   leaf metric {
                     type uint32;
                     description
                       "Значение метрики для установки, добавления или вычитания.";
                   }
                   description
                     "Установить метрику для маршрута.";
                 }
                 container set-metric-type {
                   leaf metric-type {
                     type identityref {
                       base metric-type;
                     }
                     description
                       "Тип метрики маршрута.";
                   }
                   description
                     "Установить тип метрики для маршрута.";
                 }
                 container set-route-level {
                   leaf route-level {
                     type identityref {
                       base route-level;
                     }
                     description
                       "Уровень импорта маршрута.";
                   }
                   description
                     "Набор уровней для импорта или экспорта маршрутов.";
                 }
                 leaf set-route-preference {
                   type uint16;
                   description
                     "Набор предпочтения для маршрута, называемый также
                      административной дистанцией. Это позволяет выбрать
                      предпочтительный маршрут из числа ведущих к одному
                      префиксу. Меньшее значение более предпочтительно.";
                 }
                 leaf set-tag {
                   type tag-type;
                   description
                     "Набор тегов для маршрута.";
                 }
                 leaf set-application-tag {
                   type tag-type;
                   description
                     "Устанавливает тег приложения для маршрута. Зависимый
                      от приложения тег может применяться приложениями, 
                      которым нужно отличать семантику и/или правила от
                      тега. Например, теги обычно автоматически анонсируются
                      в OSPF AS-External Link State Advertisement (LSA), а 
                      зависимые от приложения теги не анонсируются неявно.";
                 }
               }
             }
           }
         }
       }
     }
   }
   <CODE ENDS>

8. Вопросы безопасности

Заданный этим документом модуль YANG определяет схему для данных, которая обеспечивает доступ по протоколам управления сетью, таким как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищённый транспорт с обязательной реализацией протокола SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF является протокол HTTPS с обязательной реализацией защищённого транспорта TLS [RFC8446].

Модель управления доступом к конфигурации сети (Network Configuration Access Control Model или NACM) [RFC8341] позволяет разрешить доступ к предопределенным операциям протокола и содержимому лишь отдельным пользователям NETCONF или RESTCONF.

Многие узлы данных в определённом здесь модуле YANG позволяют доступ для записи, создания, удаления (writable/creatable/deletable, т. е. config true, как установлено по умолчанию). Такие узлы могут содержать конфиденциальные сведения или быть уязвимыми в некоторых сетевых средах. Операции записи (например, edit-config) для таких узлов без подобающей защиты могут отрицательно влиять на работу сети. Ниже перечислены субдеревья и узлы данных с указанием возможных уязвимостей.

/routing-policy/defined-sets/prefix-sets

Изменение набора префиксов может привести к DoS-атаке3. Злоумышленник может попытаться изменить наборы префиксов для перенаправления или отбрасывания трафика. Перенаправление может быть частью более сложной атаки для сбора конфиденциальной информации или маскировки службы. Кроме того, может быть реализована DoS-атака в плоскости управления с утечкой большого числа маршрутов в домен протокола маршрутизации (например, BGP).

/routing-policy/defined-sets/neighbor-sets

Изменение набора соседей можно использовать для организации DoS-атаки или более сложных атак как при изменении набора префиксов. Например, можно организовать DoS-атаку, меняя соседей, от которых принимаются маршруты.

/routing-policy/defined-sets/tag-sets

Изменение наборов тегов может служить для организации DoS-атак. Маршруты с некоторыми тегами могут перенаправляться или отбрасываться. Воздействие похоже на результат изменения наборов префиксов или соседей. Однако такие атаки могут быть более сложными для обнаружения, поскольку для этого нужно понимать использование политикой маршрутизации тегов маршрутов и их назначение.

/routing-policy/policy-definitions/policy-definition/statements/statement/conditions

Изменение условий можно использовать для организации DoS-атаки и иных типов атак. Атакующий может поменять условие политики и перенаправить или отбросить трафик. Как и изменение наборов префиксов, соседей и тегов, это может быть частью более сложных атак.

/routing-policy/policy-definitions/policy-definition/statements/statement/actions

Изменение действий можно использовать для организации DoS-атаки и иных типов атак с перенаправлением или отбрасыванием трафика. Как и изменение наборов префиксов, соседей и тегов, это может быть частью более сложных атак. Кроме того, могут изменяться атрибуты маршрутов для организации атак второго уровня, которые сложнее обнаружить.

Некоторые из доступных для чтения узлов модуля YANG могут считаться конфиденциальными или уязвимыми в отдельных сетевых средах. Для таких узлов важно контролировать операции чтения (например, get, get-config, notification). Ниже перечислены субдеревья и узлы данных с указанием возможных уязвимостей.

/routing-policy/defined-sets/prefix-sets

Данные из этих узлов могут быть использованы для определения локальных префиксов, уязвимых для DoS-атаки.

/routing-policy/defined-sets/neighbor-sets

Данные из этих узлов могут быть использованы для определения локальных узлов, на которые можно организовать DoS-атаку.

/routing-policy/policy-definitions/policy-definition/statements/

Данные из этих узлов можно использовать для организации DoS-атаки на локальный маршрутизатор. Кроме того, правила и входящие в них условия могут считаться «собственностью» (proprietary), из которой можно узнать партнёров, заказчиков и поставщиков. Сами правила могут включать интеллектуальную собственность и раскрытие сведений из них может привести к утрате конкурентных преимуществ.

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

9. Взаимодействие с IANA

Агентство IANA зарегистрировало показанный ниже идентификатор URI в субреестре ns реестра IETF XML Registry [RFC3688]:

   URI:  urn:ietf:params:xml:ns:yang:ietf-routing-policy
   Registrant Contact:  The IESG
   XML:  N/A; the requested URI is an XML namespace.

   IANA has registered the following YANG module in the "YANG Module
   Names" subregistry [RFC6020] within the "YANG Parameters" registry:

   Name:  ietf-routing-policy
   Maintained by IANA?  N
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-routing-policy
   Prefix:  rt-pol
   Reference:  RFC 9067

10. Литература

10.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>.

[RFC2328] Moy, J., “OSPF Version 2”, STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC3101] Murphy, P., “The OSPF Not-So-Stubby Area (NSSA) Option”, RFC 3101, DOI 10.17487/RFC3101, January 2003, <https://www.rfc-editor.org/info/rfc3101>.

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., “A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, “A Policy Control Mechanism in IS-IS Using Administrative Tags”, RFC 5130, DOI 10.17487/RFC5130, February 2008, <https://www.rfc-editor.org/info/rfc5130>.

[RFC5302] Li, T., Smit, H., and T. Przygienda, “Domain-Wide Prefix Distribution with Two-Level IS-IS”, RFC 5302, DOI 10.17487/RFC5302, October 2008, <https://www.rfc-editor.org/info/rfc5302>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[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>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8343] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, “A YANG Data Model for Routing Management (NMDA Version)”, RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.

[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

10.2. Дополнительная литература

[IDR-BGP-MODEL] Jethanandani, M., Patel, K., Hares, S., and J. Haas, “BGP YANG Model for Service Provider Networks”, Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-09, 28 June 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-09>.

[W3C.REC-xml11] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., Yergeau, F., and J. Cowan, “Extensible Markup Language (XML) 1.1 (Second Edition)”, W3C Consortium Recommendation REC-xml11-20060816, 16 August 2006, <https://www.w3.org/TR/2006/REC-xml11-20060816>.

Приложение A. Зависимые от протокола маршрутизации правила

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

Приведённый ниже пример показывает, как другая модель данных может дополнить описанную модель данных политики маршрутизации. Используются примеры из документа draft-ietf-idr-bgp-model-09 для демонстрации того, как две части могут работать совместно. Пример не является нормативным применительно к [IDR-BGP-MODEL]. Модель аналогичным способом дополняет относящиеся к BGP условия и действия в соответствующих разделах модели политики маршрутизации. В примере префикс XPath bp: указывает импорт из субмодуля ietf-bgp-policy, а префикс XPath bt: – импорт из субмодуля [IDR-BGP-MODEL].

   module: ietf-routing-policy
     +--rw routing-policy
        +--rw defined-sets
        |  +--rw prefix-sets
        |  |  +--rw prefix-set* [name]
        |  |     +--rw name        string
        |  |     +--rw mode?       enumeration
        |  |     +--rw prefixes
        |  |        +--rw prefix-list* [ip-prefix mask-length-lower
        |  |                            mask-length-upper]
        |  |           +--rw ip-prefix            inet:ip-prefix
        |  |           +--rw mask-length-lower    uint8
        |  |           +--rw mask-length-upper    uint8
        |  +--rw neighbor-sets
        |  |  +--rw neighbor-set* [name]
        |  |     +--rw name       string
        |  |     +--rw address*   inet:ip-address
        |  +--rw tag-sets
        |  |  +--rw tag-set* [name]
        |  |     +--rw name         string
        |  |     +--rw tag-value*   tag-type
        |  +--rw bp:bgp-defined-sets
        |     +--rw bp:community-sets
        |     |  +--rw bp:community-set* [name]
        |     |     +--rw bp:name      string
        |     |     +--rw bp:member*   union
        |     +--rw bp:ext-community-sets
        |     |  +--rw bp:ext-community-set* [name]
        |     |     +--rw bp:name      string
        |     |     +--rw bp:member*   union
        |     +--rw bp:as-path-sets
        |        +--rw bp:as-path-set* [name]
        |           +--rw bp:name      string
        |           +--rw bp:member*   string
        +--rw policy-definitions
           +--ro match-modified-attributes?   boolean
           +--rw policy-definition* [name]
              +--rw name          string
              +--rw statements
                 +--rw statement* [name]
                    +--rw name          string
                    +--rw conditions
                    |  +--rw call-policy?
                    |  +--rw source-protocol?          identityref
                    |  +--rw match-interface
                    |  |  +--rw interface?        if:interface-ref
                    |  +--rw match-prefix-set
                    |  |  +--rw prefix-set?       prefix-set/name
                    |  |  +--rw match-set-options?
                    |  |                         match-set-options-type
                    |  +--rw match-neighbor-set
                    |  |  +--rw neighbor-set?
                    |  +--rw match-tag-set
                    |  |  +--rw tag-set?
                    |  |  +--rw match-set-options?
                    |  |                         match-set-options-type
                    |  +--rw match-route-type
                    |     +--rw route-type*     identityref
                    |  +--rw bp:bgp-conditions
                    |     +--rw bp:med-eq?       uint32
                    |     +--rw bp:origin-eq?    bt:bgp-origin-attr-type
                    |     +--rw bp:next-hop-in*  inet:ip-address-no-zone
                    |     +--rw bp:afi-safi-in*  identityref
                    |     +--rw bp:local-pref-eq?  uint32
                    |     +--rw bp:route-type?     enumeration
                    |     +--rw bp:community-count
                    |     +--rw bp:as-path-length
                    |     +--rw bp:match-community-set
                    |     |  +--rw bp:community-set?
                    |     |  +--rw bp:match-set-options?
                    |     +--rw bp:match-ext-community-set
                    |     |  +--rw bp:ext-community-set?
                    |     |  +--rw bp:match-set-options?
                    |     +--rw bp:match-as-path-set
                    |        +--rw bp:as-path-set?
                    |        +--rw bp:match-set-options?
                    +--rw actions
                       +--rw policy-result?         policy-result-type
                       +--rw set-metric
                       |  +--rw metric-modification?
                       |  +--rw metric?                uint32
                       +--rw set-metric-type
                       |  +--rw metric-type?   identityref
                       +--rw set-route-level
                       |  +--rw route-level?   identityref
                       +--rw set-route-preference?        uint16
                       +--rw set-tag?               tag-type
                       +--rw set-application-tag?   tag-type
                       +--rw bp:bgp-actions
                          +--rw bp:set-route-origin?
                          |                    bt:bgp-origin-attr-type
                          +--rw bp:set-local-pref?   uint32
                          +--rw bp:set-next-hop?     bgp-next-hop-type
                          +--rw bp:set-med?          bgp-set-med-type
                          +--rw bp:set-as-path-prepend
                          |  +--rw bp:repeat-n?   uint8
                          +--rw bp:set-community
                          |  +--rw bp:method?      enumeration
                          |  +--rw bp:options?
                          |  +--rw bp:inline
                          |  |  +--rw bp:communities*   union
                          |  +--rw bp:reference
                          |     +--rw bp:community-set-ref?
                          +--rw bp:set-ext-community
                             +--rw bp:method?      enumeration
                             +--rw bp:options?
                             +--rw bp:inline
                             |  +--rw bp:communities*   union
                             +--rw bp:reference
                                +--rw bp:ext-community-set-ref?

Приложение B. Примеры политики

Ниже приведены примеры XML-представления данных конфигурации с использованием моделей политики маршрутизации и BGP для иллюстрации определения и применения политики. Отметим, что язык XML [W3C.REC-xml11] был упрощён для удобочитаемости.

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

     <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <routing-policy
        xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">

           <defined-sets>
             <prefix-sets>
               <prefix-set>
                 <name>prefix-set-A</name>
                 <mode>ipv4</mode>
                 <prefixes>
                   <prefix-list>
                     <ip-prefix>192.0.2.0/24</ip-prefix>
                     <mask-length-lower>24</mask-length-lower>
                     <mask-length-upper>32</mask-length-upper>
                   </prefix-list>
                   <prefix-list>
                     <ip-prefix>198.51.100.0/24</ip-prefix>
                     <mask-length-lower>24</mask-length-lower>
                     <mask-length-upper>32</mask-length-upper>
                   </prefix-list>
                 </prefixes>
               </prefix-set>
               <prefix-set>
                 <name>prefix-set-B</name>
                 <mode>ipv6</mode>
                   <prefixes>
                   <prefix-list>
                     <ip-prefix>2001:DB8::/32</ip-prefix>
                     <mask-length-lower>32</mask-length-lower>
                     <mask-length-upper>64</mask-length-upper>
                   </prefix-list>
                 </prefixes>
               </prefix-set>
              </prefix-sets>
              <tag-sets>
               <tag-set>
                <name>cust-tag1</name>
                <tag-value>10</tag-value>
              </tag-set>
            </tag-sets>
          </defined-sets>

          <policy-definitions>
           <policy-definition>
             <name>export-tagged-BGP</name>
             <statements>
               <statement>
                 <name>term-0</name>
                 <conditions>
                   <match-prefix-set>
                     <prefix-set>prefix-set-A</prefix-set>
                   </match-prefix-set>
                   <match-tag-set>
                     <tag-set>cust-tag1</tag-set>
                   </match-tag-set>
                 </conditions>
                 <actions>
                   <policy-result>accept-route</policy-result>
                 </actions>
               </statement>
             </statements>
           </policy-definition>
         </policy-definitions>

       </routing-policy>
   </config>

В следующем примере все маршруты в RIB получаются из анонсов OSPF, соответствующих внутриобластным и межобластным типам маршрутов OSPF, которые следует передать в анонсы IS-IS уровня 2.

   <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <routing-policy
      xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
      <policy-definitions>
       <policy-definition>
        <name>export-all-OSPF-prefixes-into-IS-IS-level-2</name>
         <statements>
          <statement>
            <name>term-0</name>
            <conditions>
              <match-route-type>
                <route-type>ospf-internal-type</route-type>
              </match-route-type>
            </conditions>
            <actions>
              <set-route-level>
                <route-level>isis-level-2</route-level>
              </set-route-level>
              <policy-result>accept-route</policy-result>
            </actions>
          </statement>
         </statements>
       </policy-definition>
      </policy-definitions>
     </routing-policy>
   </config>

Благодарности

Определённый в этом документе модуль политики маршрутизации основан на модели политики маршрутизации OpenConfig. Авторы признательны разработчикам OpenConfig за их вклад, особо отмечая Anees Shaikh, Rob Shakir, Kevin D’Souza, Chris Chase.

Авторы благодарны Ebben Aires, Luyuan Fang, Josh George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, John Heasley за ценный вклад в этот документ и связанные с ним модели.

Спасибо Mahesh Jethanandani, John Scudder, Alvaro Retana, Chris Bowers, Tom Petch, Kris Lambrechts за их рецензии и комментарии.

Адреса авторов

Yingzhen Qu
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yingzhen.qu@futurewei.com
 
Jeff Tantsura
Microsoft
Email: jefftant.ietf@gmail.com
 
Acee Lindem
Cisco
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee@cisco.com
 
Xufeng Liu
Volta Networks
Email: xufeng.liu.ietf@gmail.com

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Denial-of-Service – отказ в обслуживании.

Рубрика: RFC | Оставить комментарий

RFC 9119 Multicast Considerations over IEEE 802 Wireless Media

image_print
Internet Engineering Task Force (IETF)                        C. Perkins
Request for Comments: 9119                                   Lupin Lodge
Category: Informational                                       M. McBride
ISSN: 2070-1721                                                Futurewei
                                                              D. Stanley
                                                                     HPE
                                                               W. Kumari
                                                                  Google
                                                              JC. Zúñiga
                                                                  SIGFOX
                                                            October 2021

Multicast Considerations over IEEE 802 Wireless Media

Групповая передача в беспроводных средах IEEE 802

PDF

Аннотация

Хорошо известные проблемы с групповой адресацией (multicast) помешали развёртыванию группового взаимодействия в сетях 802.11 (Wi-Fi) и других беспроводных средах локального действия. В этом документе описаны известные ограничения группового обмена на канальном уровне (L2) в беспроводных сетях (в основном 802.11). Описаны также некоторые возможности улучшения, найденные IETF и IEEE 802 для беспроводных сред, а также некоторые варианты использования, способные повысить производительность сетей. Кроме того, приведены некоторые рекомендации по использованию и комбинированию этих улучшений, а также рассмотрены вопросы эксплуатации.

Статус документа

Документ относится к категории информационных и не задаёт стандартов Internet.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9119.

Авторские права

Авторские права (Copyright (c) 2021) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML.

1. Введение

Хорошо известные проблемы с групповой адресацией помешали развёртыванию группового взаимодействия в сетях 802.11 [dot11] и других локальных беспроводных средах, как описано в [mc-props] и [mc-prob-stmt]. Проблемы наблюдались при групповой адресации в протоколах IETF, использующих беспроводные среды IEEE 802. Хотя улучшения для групповой передачи были разработаны в IETF и IEEE 802, между спецификациями и реализациями, а также настройками сохраняется несовместимость.

Многие протоколы IETF зависят от широковещательной или групповой доставки управляющих сообщений множеству получателей. Групповая адресация позволяет передать данные множеству заинтересованных получателей без необходимости отправки копии каждому. При широковещательной передаче данные отправляются каждому устройству, независимо от его заинтересованности в них. Групповая передача применяется для таких целей, как обнаружение соседей (Neighbor Discovery или ND), лавинная рассылка по сети и распознавание адресов, а также для снижения нагрузки на сеть при передаче данных, предназначенных множеству адресатов. Помимо использования широковещательной и групповой передачи для пакетов управления, её применяют многие приложения, такие как Push To Talk3 в больницах, видеослужбы на предприятиях, университетах и в жилых домах, отправляя групповые пакеты IP устройствам конечных пользователей, которые все чаще применяют Wi-Fi.

Протоколы IETF обычно полагаются на многоуровневую структуру протоколов для снижения или исключения зависимости протоколов более высокого уровня от конкретной природы уровня MAC или физической среды. В случае групповой передачи протоколы верхних уровней обычно разрабатывались в предположении, что передача пакета по адресу IP равноценна в плане помех и доступа к сетевой среде, независимо от использования индивидуального, группового или широковещательного IP-адреса получателя. Эта модель подходит для сетей с передачей по кабелю, таким как Ethernet. К сожалению во многих беспроводных средах «стоимость» доступа к среде может существенно меняться. Групповая передача через сеть Wi-Fi часто имеет столь низкую производительность, что её просто не разрешают. Были разработаны некоторые усовершенствования для протоколов IETF, которые предполагалось использовать в основном в беспроводных средах. Однако эти улучшения обычно не получали широкого распространения в большинстве беспроводных сетей.

Беспроводные протоколы IEEE 802 были разработаны с некоторыми функциями для поддержки группового трафика. Например, для передачи групповых кадров применяется более низкая частота модуляции и они могут быть получены всеми станциями в ячейке, независимо от расстояния и затухания на пути от базовой станции или точки доступа (Access Point или AP). Однако такие передачи с более низкочастотной модуляцией дольше занимают среду, препятствуя эффективной передаче трафика с более высокочастотной модуляцией для расположенных близко станций. По этой и другим причинам рабочие группы IEEE 802, такие как 802.11, разработали средства повышения эффективности групповой передачи на уровне L2 [ietf_802-11]. Дополнительное улучшение работы при использовании групповой передачи может быть достигнуто с помощью некоторых эксплуатационных и конфигурационных решений (см. раздел 5).

Похоже, все уже согласились с тем, что эти проблемы не будут решены в ближайшее время в первую очередь из-за того, что это дорого и групповая передача не обеспечивает надёжности. По сравнению с индивидуальным трафиком Wi-Fi, групповой рассматривается как нечто второсортное, несмотря на наличие множества протоколов, использующих multicast-передачу. Нужны какие-то средства повышения надёжности групповой передачи. Протокол IPv6 ND, насыщающий каналы Wi-Fi является лишь частью проблемы. В решении могут помочь классы трафика Wi-Fi. Этот документ нацелен на прояснение вопроса о том, какие проблемы следует решать в IETF, а какие – в IEEE (раздел 8).

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

2. Терминология

ACK

Подтверждение канального уровня 802.11 L2.

AES-CCMP

Протокол AES-Counter Mode CBC-MAC.

AP

Точка доступа IEEE 802.11.

Basic rate – базовая скорость

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

DVB-H

Digital Video Broadcasting – Handheld – переносное устройство для цифрового приёма видео.

DVB-IPDC

Digital Video Broadcasting – Internet Protocol Datacasting – передача данных IP через цифровое вещание видео.

DTIM

Delivery Traffic Indication Map (карта индикации доставки трафика) – информационный элемент, сообщающий о наличии или отсутствии у ассоциированных станций буферизованных групповых или широковещательных кадров.

MCS

Modulation and Coding Scheme – схема модуляции и кодирования.

NOC

Network Operations Center – сетевой операционный центр.

PER

Packet Error Rate – частота ошибок в пакетах.

STA

Станция 802.11 (например, переносное устройство).

TIM

Traffic Indication Map (карта индикации трафика) – информационный элемент, сообщающий о наличии или отсутствии у ассоциированных станций буферизованных индивидуальных кадров.

TKIP

Temporal Key Integrity Protocol – протокол защиты целостности временных ключей.

WiMAX

Worldwide Interoperability for Microwave Access

WPA

Wi-Fi Protected Access – защищённый доступ к Wi-Fi.

3. Известные проблемы групповой передачи

3.1. Проблемы на уровне L2 и ниже

В этом параграфе описаны некоторые проблемы, связанные с использованием групповой передачи в беспроводных сетях IEEE 802.

3.1.1. Ненадёжность групповой передачи

Надёжность группового трафика обычно значительно ниже, чем индивидуального. Поскольку для групповой передачи применяется режим «один со многими», для подтверждения доставки требуется передача множества пакетов. Однако для групповой передачи подтверждения (ACK) не применяются и точка доступа (AP) не знает, требуется ли повторная отправка. Даже в кабельной части Internet с этим зачастую связан нежелательно высокий уровень ошибок. В результате групповые приложения внедряются сравнительно медленно, хотя протоколы для них давно доступны. В беспроводных сетях ситуация значительно хуже и очень чувствительна к наличию фонового трафика. В результате может наблюдаться очень высокая частота пакетных ошибок (packet error rate или PER) из-за отсутствия повторов передачи и снижения скорости отправки. PER представляет собой долю (в процентах) пакетов, которые не были получены устройством. Нередко этот уровень превышает 5%, что особенно неприятно для видео и других данных, где нужна высокая скорость и надёжность.

3.1.2. Низкая и переменная скорость передачи данных

Групповая передача по кабелям отличается от беспроводной, поскольку кабельные каналы обычно работают на фиксированной скорости. Скорость передачи в Wi-Fi зависит от близости STA к AP. Полоса видеопотоков и пропускная способность в большой сети Wi-Fi будет меняться при перемещении устройства. Это влияет на возможности решений QoS эффективно резервировать пропускную способность и обеспечивать контроль подачи данных в сеть.

Для аутентифицированных и подключённых к AP беспроводных станций мощность, требуемая для хорошего приёма может существенно меняться от станции к станции. Для индивидуальной передачи целью является минимальное энергопотребление при максимальной скорости доставки данных получателю. Для групповой передачи цель заключается в достижении максимального числа получателей, которые могут корректно принять групповые пакеты. Обычно AP должна использовать существенно меньшую скорость передачи при высоком потреблении энергии, чтобы даже самая удалённая станция получила пакет, например, как кратко описано в разделе 4 [RFC5757]. Поэтому скорость передачи, например, видеопотока может быть ограничена окружением менее надёжного получателя, подключённого к AP.

Поскольку более отказоустойчивые схемы модуляции и кодирования (modulation and coding scheme или MCS) обеспечивают большую дальность, но меньшую скорость, широковещательный и групповой трафик обычно передаётся с наименьшей среди всех подключённых устройств скоростью. Эту скорость называют базовой. Уровень дополнительных помех зависит от конкретной беспроводной технологии. Фактически, совместимость с более старыми устройствами и многопоточные реализации позволяют передавать индивидуальный трафик со скоростью несколько Гбит/с, а разница скорости передачи группового или широковещательного трафика и оптимальной скорости индивидуального трафика может превышать 3 порядка. Некоторые методы повышения спектральной эффективности, такие как пространственное мультиплексирование в системах с несколькими входами и выходами (Multiple Input Multiple Output или MIMO) недоступны для нескольких получателей. Совместимость со старыми версиями не является единственным фактором ограничения скорости групповой передачи.

Проводная групповая передача также влияет на беспроводные LAN, когда AP служит расширением кабельного сегмента. В этом случае групповые и широковещательные кадры на проводной стороне ЛВС копируются в беспроводную сеть (Wireless Local Area Network или WLAN). Поскольку широковещательные сообщения передаются с более отказоустойчивыми схемами MCS, многие большие кадры отправляются с малой скоростью через беспроводный канал.

3.1.3. Пропускная способность и влияние на помехи

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

3.1.4. Влияние энергосбережения на групповой трафик

Одной из характеристик групповой передачи в Wi-Fi является настройка каждой станции на пробуждение по приёму группового кадра, даже если тот будет в итоге отброшен. Это оказывает сильное влияние на потребляемую станцией энергию. По этой причине были найдены некоторые обходные пути, такие как направленная групповая передача (Directed Multicast Service или DMS), описанная в разделе 4, чтобы избежать пробуждения станций.

Групповая и индивидуальная передача может плохо работать с механизмами энергосбережения IEEE 802.11e в силу перечисленных ниже причин.

  • Клиенты могут быть не способны оставаться в спящем режиме из-за частого пробуждения групповыми пакетами управления.

  • Индивидуальный пакет задерживается, пока STA не проснётся и не запросит его. Задержка индивидуального трафика может также служить для экономии энергии, а также повышения эффективности и вероятности агрегирования.

  • Групповой трафик задерживается в беспроводной сети, если любая из STA в сети применяет энергосбережение. Все STA, связанные с AP, должны быть активны для получения группового трафика.

  • Пакеты могут отбрасываться из-за ограничений буферов в AP и STA без AP.

3.2. Проблемы на уровне L3 и выше

В этом параграфе рассматриваются некоторые протоколы IETF и возможное снижение их производительности при использовании групповых управляющих сообщений. Типичными примерами использования групповых пакетов служат:

  • сигнализация плоскости управления;

  • обнаружение соседей;

  • распознавание адресов;

  • обнаружение служб;

  • приложения (доставка видео, данных складов и т. п.);

  • маршрутизация по запросу;

  • создание магистрали;

  • другие протоколы L3 (не IP).

Протокол пользовательских дейтаграмм (User Datagram Protocol или UDP наиболее распространён для доставки группового трафика. Сам по себе, протокол UDP не обеспечивает гарантий и сообщения могут теряться или менять порядок доставки.

3.2.1. Проблемы IPv4

Ниже представлены некоторые типовые протоколы обнаружения, использующие групповую или широковещательную передачу по протоколу IPv4.

  • ARP [RFC0826].

  • DHCP [RFC2131].

  • Multicast DNS (mDNS) [RFC6762].

  • Universal Plug and Play (uPnP) [RFC6970].

После начальной настройки ARP (см. ниже), DHCP и uPnP применяются достаточно редко, но обнаружение служб может происходить в любой момент. Некоторые широко распространённые протоколы обнаружения служб (например, для поиска принтеров) используют механизм mDNS (групповой), который операторы часто блокируют. Даже при отслеживании групповой передачи [RFC4541] (которое обеспечивает сохранение пропускной способности сегментов сети, где ни один узел не заявил интереса в получении пакетов по этому групповому адресу) одновременно может регистрироваться много устройств, существенно снижая производительность сети.

3.2.2. Проблемы IPv6

В IPv6 групповая передача применяется более широко, включая протоколы:

  • DHCPv6 [RFC8415];

  • Protocol Independent Multicast (PIM) [RFC7761];

  • IPv6 Neighbor Discovery Protocol (NDP) [RFC4861];

  • Multicast DNS (mDNS) [RFC6762];

  • Router Discovery [RFC4286].

Сообщения IPv6 NDP Neighbor Solicitation (NS) при обнаружении дубликатов адресов (Duplicate Address Detection или DAD) и поиске адресов могут использовать групповую адресацию с областью действия на локальном канале (link-scope). В отличие от IPv4, узел IPv6 обычно использует несколько адресов и может часто менять их по соображениям приватности. Влияние групповых сообщений возрастает при мобильности устройств. Анонсы маршрутизаторов (Router advertisement или RA) также периодически передаются по групповым адресам.

Сосед может считаться потерянным при отказе нескольких пакетов Neighbor Discovery подряд.

3.2.3. Проблемы MLD

Обнаружение слушателей группового трафика (Multicast Listener Discovery или MLD) [RFC4541] применяется для обнаружения членов multicast-группы, подключённых к портам коммутатора. Пересылка групповых кадров в область с поддержкой Wi-Fi может использовать поддержку коммутатором сведений о пересылке на аппаратном уровне. По причине интенсивного применения групповой передачи в IPv6 для каждой станции STA с адресом IPv6 потребуется хранить в коммутаторе состояние для нескольких (возможно многих) групповых адресов solicited-node. Это групповые адреса IPv6Ю используемые протоколом NDP для проверки занятости адресов IPv6 на локальном канале. Групповые адреса, для которых не установлено состояние пересылки (возможно по причине недостатка памяти в коммутаторе), будут вызывать лавинную рассылку во все порты коммутатора. Некоторые производители коммутаторов не поддерживают MLD для групповой передачи link-scope, по причине требований к поддержке состояний.

3.2.4. Ложное обнаружение соседей

В Internet существует фоновое сканирование трафика (люди, занимающиеся поиском уязвимых машин) и «обратное рассеяние» (отклики на обманный трафик и т. п.). Это означает, что маршрутизаторы очень часто передают пакеты по адресам IPv4, которые могут не использоваться. При назначении IP-адреса хосту маршрутизатор передаёт широковещательный запрос ARP, получает отклик ARP и кэширует его, а затем трафик может быть доставлен хосту. Когда IP-адрес не используется, маршрутизатор передаёт 1 или несколько широковещательных запросов ARP и не получает на них отклика. Это означает, что запись в кэш ARP не вносится и следующий пакет по этому адресу IP приведёт к новой широковещательной передаче запросов ARP.

Частота этих запросов ARP пропорциональна размеру подсетей, темпам сканирования и обратного рассеяния, а также времени хранения маршрутизатором состояний для отсутствия ответов ARP. Оказывается, что эта частота обратно пропорциональная заполненности подсети (действительные ARP сохраняются в кэше без широковещательных повторов, а неиспользуемые адреса IP не отвечают на запросы, что увеличивает широковещательный трафик). В зависимости от используемого пространства адресов, времени суток, заполненности сети и других (неизвестных) факторов могут наблюдаться тысячи широковещательных пакетов в секунду. Наблюдалось около 2000 широковещательных пакетов в секунду в сети IETF NOC во время конференций.

С помощью протокола Neighbor Discovery для IPv6 [RFC4861] узлы распознают адреса путём групповой передачи сообщений Neighbor Solicitation, запрашивающих у узлов адрес канального уровня. Сообщения Neighbor Solicitation передаются по групповому адресу solicited-node. Целевой узел возвращает адрес канального уровня в индивидуальном сообщении Neighbor Advertisement. Одной пары пакетов с запросом и откликом достаточно для инициатора и цели, чтобы узнать адреса канального уровня друг друга (инициатор включает его в Neighbor Solicitation).

В кабельных сетях нет большой разницы между индивидуальным, групповым и широковещательным трафиком. В результате аппаратной фильтрации (см., например, [Deri-2010]) непреднамеренный лавинный трафик (или избыточные групповые кадры Ethernet) в кабельной сети может быть значительно «дешевле» по сравнению с беспроводными сетями, где спящие устройства пробуждаются для обработки пакетов. Кабельные сети Ethernet как правило являются коммутируемыми, что дополнительно снижает помехи от группового трафика. Фактически не возникает проблем с коллизиями и планированием за исключением случаев чрезвычайно высокой загрузки порта. В беспроводных сетях это не так и оборудование зачастую неспособно передавать большие объёмы широковещательного и группового трафика, что ведёт к отбрасыванию значительной части таких пакетов. Поэтому при подключении хоста он зачастую не может завершить процедуру DHCP и пакеты IPv6 RA отбрасываются, что препятствует доступу пользователя в сеть.

4. Оптимизация группового протокола

В этом разделе описаны некоторые пути оптимизации, предложенные в IEEE 802 и IETF для смягчения или исключения проблем, отмеченных в разделе 3.

4.1. Proxy ARP в 802.11-2012

AP знает адреса L2 (Medium Access Control или MAC) и IP всех связанных с ней STA. Таким образом, AP выступает центральным «менеджером» для всех 802.11 STA в наборе базовых служб (Basic Service Set или BSS). Proxy ARP легко реализовать на AP, обеспечив указанные ниже преимущества.

  • Снижение широковещательного трафика (передаётся с низкими MCS) в беспроводной среде.

  • STA может более эффективно использовать спящий режим, поскольку запросы ARP для её адреса IP обрабатывает AP.

  • Кадры ARP не попадают в беспроводную среду.

  • Не требуется менять реализации STA.

Ниже приведён фрагмент спецификации из параграфа 10.23.13 [dot11-proxyarp].

Когда AP поддерживает Proxy ARP «[…] AP нужно поддерживать сопоставление аппаратных адресов с адресами Internet для каждой связанной станции и обновлять сопоставление при смене станцией адреса Internet. При преобразовании адреса IPv4 с помощью запроса ARP от станции STA без AP, связанной с BSS, службе Proxy ARP нужно отвечать от имени STA на запрос ARP или пакет ARP Probe.

4.2. Регистрация адресов IPv6 и Proxy ND

В этом параграфе персональной беспроводной со слабым питанием (Low-Power Wireless Personal Area Network или 6LoWPAN) считается сеть со слабым питанием и потерями (Low-Power and Lossy Network или LLN), поддерживающая сжатие заголовков 6LoWPAN (Header Compression или HC) [RFC6282]. Примером 6LoWPAN является сеть 6TiSCH [RFC9030]. Для контроля использования групповой передачи IPv6 через сети 6LoWPAN разработан стандарт 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775], определяющий механизм регистрации адресов на основе центрального реестра, контролирующего уникальность адресов вместо неэффективного механизма DAD применяемого протоколом обнаружения соседей IPv6 (Neighbor Discovery Protocol или NDP) [RFC4861] [RFC4862].

Рабочая группа 6lo подготовила обновление [RFC6775]. Беспроводное устройство может регистрировать свой адрес на магистральном маршрутизаторе (Backbone Router) [RFC8929], который служит посредником к IPv6 NDP, работающему высокоскоростной магистрали агрегирования. Обновление также включает механизм прокси-регистрации от имени зарегистрированного узла, например, через маршрутизатор 6LoWPAN, к которому подключён мобильный узел.

Общая идея концепции магистрального маршрутизатора заключается в том, что широковещательные и групповые сообщения следует строго контролировать в разных WLAN и персональных беспроводных сетях (Wireless Personal Area Network или WPAN). Связность с конкретным каналом, обеспечивающим подсеть, следует сохранить на уровне L3. Модель работы Backbone Router показана на рисунке 1.

          |
        +-----+
        |     | Принятый по умолчанию маршрутизатор
        |     |
        +-----+
           |
           |      Магистральный канал
     +--------------------+------------------+
     |                    |                  |
  +-----+             +-----+             +-----+
  |     |Магистральный|     |Магистральный|     |Магистральный
  |     |маршрутиз. 1 |     |маршрутиз. 2 |     |маршрутиз. 3
  +-----+             +-----+             +-----+
     o                o   o  o              o o
 o o   o  o       o o   o  o  o         o  o  o  o o
o  o o  o o       o   o  o  o  o        o  o  o o o
o   o  o  o          o    o  o           o  o   o
  o   o o               o  o                 o o

    LLN 1              LLN 2                LLN 3

Рисунок 1. Магистральный канал и магистральные маршрутизаторы.

Узлы LLN могут свободно перемещаться из сети LLN, привязанной к одному магистральному маршрутизатору IPv6 BR, в сеть, привязанную к другому BR на той же магистрали, сохраняя все настроенные адреса IPv6. Маршрутизаторы BR поддерживают таблицу привязки (Binding Table) своих зарегистрированных адресов, которая служит распределенной базой данных обо всех узлах LLN. Расширение протокола NDP введено для обмена данными таблиц привязки через магистральный канал (Backbone Link) для обеспечения работы IPv6 Neighbor Discovery.

В [RFC6775] и последующем документе [RFC8505] рассматриваются потребности LLN и похожих методов, которые вероятно будут полезны для каналов любого типа, где подключены спящие устройства или следует ограничить широковещательный и групповой трафик.

4.3. Буферизация для увеличения срока службы батареи

Разработаны методы, позволяющие продлить срок службы батареи. Например, устройство может не просыпаться при получении точкой доступа (AP) группового пакета. AP действует от имени STA разными способами. Для включения функций экономии энергии в STA в своём наборе BSS точка доступа AP буферизует предназначенные STA кадры до времени, когда STA планирует приём. Если AP, например, выражает сообщение индикации доставки трафика (Delivery Traffic Indication Message или DTIM) 3, AP будет передавать групповой пакет через каждые 3 пакета. Фактически, когда любая отдельная беспроводная станция STA, связанная с AP, имеет включенный режим энергосбережения 802.11, AP буферизует все групповые кадры и передаёт их лишь после следующего сигнала DTIM.

На практике большинство AP будет передавать групповые пакеты каждые 30 секунд. Для индивидуальных пакетов AP может передавать сообщение индикации трафика (Traffic Indication Message или TIM), но для группового трафика AP передаёт широковещательное сообщение всем. DTIM управляет питанием, но STA могут сами решить, нужно ли просыпаться и когда отбрасывать пакет. К сожалению без должной административной настройки такие STA могут быть не способны определить, почему их групповые операции не работают.

4.4. Ограничение глубины аппаратной очереди группового буфера

Очередь CAB (Content after Beacon) служит для передачи буферизованных групповых кадров по сигналу. Если буферизовано много групповых кадров и очередь заполнена, она «заглушает» весь обычный трафик. Для ограничения ущерба, который может нанести буферизованный трафик, некоторые драйверы ограничивают объем групповых данных в очереди до доли beacon_interval. Пример этого приведён в [CAB].

4.5. Поддержка IPv6 в 802.11-2012

IPv6 использует NDP вместо ARP. Каждый узел IPv6 подписан для этого на специальный групповой адрес. Ниже приведён фрагмент текста из параграфа 10.23.13 в [dot11-proxyarp].

При распознавании адреса IPv6 службе Proxy Neighbor Discovery нужно отвечать сообщением Neighbor Advertisement […] от имени связанной станции STA на сообщение [ICMPv6] Neighbor Solicitation […]. При смене сопоставления с MAC-адресом AP может передавать незапрошенные сообщения Neighbor Advertisement от имени STA.

Протокол NDP можно использовать для запроса дополнительных данных с использованием разных методов, включая:

  • Maximum Transmission Unit;

  • Router Solicitation;

  • Router Advertisement.

Сообщения NDP передаются как групповые (широковещательные) кадры 802.11. Использование прокси помогает сохранять сообщения NDP вне беспроводной среды.

4.6. Использование индивидуальной передачи вместо групповой

Зачастую можно передать групповые сообщения управления и данных индивидуально каждой станции.

4.6.1. Обзор

Во многих случаях через канал Wi-Fi лучше передавать индивидуальные пакеты вместо групповых. Это избавляет от большинства проблем, связанных с групповой передачей через Wi-Fi, поскольку индивидуальные кадры подтверждаются и буферизуются для клиентов с энергосбережением. При таком подходе иногда приходится один и тот же пакет передавать несколько раз через канал Wi-Fi. Однако во многих случаях, таких как передача видео в домашней сети, это обеспечивает хороший компромисс, поскольку канал Wi-Fi имеет достаточную ёмкость для индивидуального трафика для каждой подписавшейся STA, даже если на восходящем канале в сеть доступа применяется multicast.

Имеется несколько технологий, которые можно применять для индивидуальной передачи через Wi-Fi.

4.6.2. Преобразование на уровне L2

Зачастую можно передать групповые сообщения управления и данных индивидуально каждой станции.

Хотя пока нет стандартизованного метода преобразования, имеется по меньшей мере одна широко распространённая реализация в коде моста Linux [bridge-mc-2-uc]. Разные производители также имеют свои фирменные решения. В общем случае эти реализации выполняют прямое сопоставление для групп и каналов, обнаруженный при отслеживании IGMP и MLD, в соответствующие индивидуальные адреса MAC.

4.6.3. Направленная групповая передача DMS

DMS (Directed Multicast Service) позволяет STA запросить у AP передачу адресованных в группу кадров, предназначенных для запрашивающих STA в виде кадров с индивидуальным адресом (преобразовать в unicast). Ниже указаны некоторые характеристики DMS.

  • Требуются блоки агрегирования данных сервиса 802.11n MAC (Aggregate MAC Service Data Unit или A-MSDU).

  • Кадры с индивидуальными адресами подтверждаются и буферизуются для энергосберегающих STA.

  • Запрашивающая STA может указать характеристики для трафика DMS.

  • Служба DMS определена в IEEE Std 802.11v-2011 [v2011].

  • DMS требует изменений в реализациях AP и STA.

Служба DMS в настоящее время ещё не реализована в продукции. Дополнительная информация доступна в [Tramarin2017] и [Oliva2013].

4.6.4. Автоматическое туннелирование AMT

AMT (Automatic Multicast Tunneling) [RFC7450] обеспечивает возможность туннелирования групповых пакетов IP в индивидуальных пакетах через сеть, поддерживающую лишь unicast-передачу. Когда операционная система или приложение на станции STA имеет встроенный шлюз AMT, она может использовать индивидуальную адресацию для передачи по каналу Wi-Fi, развернув ретранслятор AMT в не относящейся к Wi-Fi части сети, соединённой с AP.

Рекомендуется в сетях с поддержкой групповой передачи, где развёрнуты ретрансляторы AMT, обеспечивать локальное обнаружение этих ретрансляторов с использованием описанных в [RFC8777] методов:

  • обнаружение служб на основе DNS (DNS-SD) [RFC6763];

  • общеизвестные адреса IP из раздела 7 в [RFC7450].

Шлюз AMT, реализующий несколько стандартных методов обнаружения, с большей вероятностью найдёт локальную сеть с поддержкой групповой адресации нежели организует соединение с нелокальным ретранслятором AMT восходящего направления.

4.7. GroupCast с повторами (GCR)

Механизм GCR (GroupCast with Retries, [dot11aa]) повышает надёжность за счёт использования незапрошенных повторов или механизма подтверждения блока. GCR повышает вероятность получения групповых кадров, но все же не обеспечивает гарантии.

Для механизма подтверждения блоков AP использует для каждого адресованного в группу кадра обычную групповую передачу. Повторные передачи адресуются в группу, но скрыты от STA, не поддерживающих 802.11aa. Применяется схема направленного подтверждения блоков для сбора статуса приёма от получателей и на основе этого выполняется повтор передачи.

GCR подходит для групп любого размера. По мере роста числа устройств в группе GCR может передавать запросы подтверждения блоков небольшим частям группы. GCR не требует менять реализации AP и STA.

GCR может вносить неприемлемую задержку. После отправки группы кадров данных AP выполняет ряд действий:

  • индивидуальная передача запроса подтверждения блока (Block Ack Request или BAR) части группы;

  • ожидание соответствующего подтверждения блока (Block Ack или BA);

  • повтор пропущенных кадров;

  • восстановление других операций, которые могли быть задержаны.

Такая задержка может быть неприемлема для некоторых типов трафика.

В 802.11 разрабатываются расширения для повышения производительности GCR:

  • запросы BAR передаются с использованием нисходящего многопользовательского MIMO (MU-MIMO);

  • отклики BA передаются с использованием восходящего MU-MIMO (свойство IEEE 801.11ax-2021);

  • задержка может быть дополнительно снижена одновременным получением данных BA от нескольких STA.

5. Эксплуатационная оптимизация

В этом разделе описаны некоторые варианты эксплуатационной оптимизации, которые могут быть реализованы при развёртывании беспроводных сетей IEEE 802 для смягчения проблем, описанных в разделе 3.

5.1. Устранение проблем ложного обнаружения соседей

ARP Sponge

ARP Sponge размещаются в сети и узнают реально применяемые адреса IP. Они также прослушивают запросы ARP и, видя ARP для адреса IP, который по их мнению не используется, будут передавать в ответ свой MAC-адрес. Это значит, что маршрутизатор будет иметь сопоставление IP-MAC, которое он кэширует. Если позднее этот адрес IP будет выделен машине (например, через DHCP), ARP Sponge увидит это и прекратит отвечать для него. Беспричинные (Gratuitous) ARP (или ARP от машин к их шлюзам) будут заменять подменный адрес (sponged) в ARP-таблице маршрутизатора. Этот метод достаточно эффективен, но к сожалению демоны ARP Sponge не были предназначены для такого применения – один из наиболее распространённых ARP Sponge [arpsponge] был разработан для борьбы с исчезновением участников обмена в IXP (Internet Exchange Point) и тоже не оптимизирован для такой задачи. Для каждой подсети нужен один демон, настройка сложна (скорость сканирования, плотность заполнения, число повторов и т. п.), а иногда демон просто останавливается, что требует перезапуска, вызывающего нарушения работы.

Маршрутизаторы

Некоторые маршрутизаторы (часто на основе Linux) реализуют демон негативного кэширования ARP. Если маршрутизатор не видит откликов на ARP, можно задать сохранение этой информации в течение некоторого времени. К сожалению, часто используемые в ядре маршрутизаторы не поддерживают этого. Вместо этого при получении адреса IP подключившимся к сети хостом он передаёт запрос ARP для принятого по умолчанию шлюза (маршрутизатора). Маршрутизатор обновляет свой кэш, включая в него сопоставление IP с MAC-адресом хоста из запроса (пассивное обучение ARP).

Фильтрация неиспользуемых адресов

Распределение пользователей в беспроводных (под)сетях может меняться в различных вариантах применения, таких как конференции (например, переименовываются SSID (Service Set Identifier), некоторые SSID становятся непопулярными и т. п.). Это осложняет прогнозирование использования конкретных SSID, но его можно отслеживать по мере использования сетей. Настройка нескольких пулов DHCP в подсети и их последующее включение позволяет создавать большую подсеть, в которой используются лишь младшие части адресов. Это позволяет применять входные списки доступа по IP, блокирующие старшие адреса, которые не используются. Маршрутизатор не пытается пересылать пакеты в старшие части пространств адресов и не использует для них ARP. Этот метод показал свою эффективность, но он достаточно трудоёмкий и требует координации.

Запрет и фильтрация запросов ARP

В общем случае маршрутизатору не нужны запросы ARP для хостов, он может получить сопоставление IP-MAC из переданного хостом при подключении запроса ARP. Поэтому следует обеспечивать возможность запрета и/или фильтрации запросов ARP от маршрутизатора. К сожалению ARP является фундаментальной и низкоуровневой частью стека IP и зачастую выгружается из обычной плоскости управления. Хотя многие маршрутизаторы могут фильтровать трафик на уровне L2, обычно это реализовано в форме входного фильтра, а возможности выходной фильтрации широковещательного трафика ограничены. Это означает, что кажущееся очевидным решение просто отключить или фильтровать ARP на выходе на практике сложно выполнить или оно ограничено реализацией или архитектурой.

Трансляция NAT

Широковещательная передача часто может вызываться сканированием или обратным рассеянием извне Wi-Fi. Для снижения влияния широковещания можно применять трансляцию NAT для всей (или большей части) сети. Для неиспользуемых адресов в NAT не будет записей и маршрутизатор не будет применять ARP для них. Однако имеется много причин отказываться от применения NAT в таком режиме.

Межсетевые экраны с учётом состояния

Другим очевидным решением является установка межсетевого экрана с поддержкой состояний между беспроводной сетью и Internet. Этот экран будет блокировать входящий трафик, не связанный с исходящими запросами. Однако такой подход не согласуется с необходимостью и желанием некоторых организаций делать сеть максимально открытой и соблюдать сквозные (end-to-end) принципы. Участникам сети конференции следует оставаться хостами Internet и иметь возможность получения незапрошенных сообщений. Однако поддержка работоспособности и стабильности сети важнее и для этого может потребоваться межсетевой экран с поддержкой состояний.

5.2. Устранение ложных сообщений обнаружения служб

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

6. Групповая передача в других беспроводных средах

Многие из описанных выше случаев потери производительности наблюдались и в беспроводных сетях, отличных от 802.11. Например, проблемы с энергосбережением, избыточной загрузкой среды и малой надёжностью проявляются также в сетях 802.15.3 и 802.15.4. К сожалению спецификация среды 802.15 пока не включает механизмов, подобных разработанным для 802.11. Фактически проектирование 802.15 нацелено на минимизацию и многие функции реализуются в протоколах вышележащих уровней. Это ведёт к мешанине несовместимых и фирменных решений. В [uli] подробно рассматриваются проблемы и представлены предложения для группы задач, решающие проблемы, где объем групповых передач можно снизить.

Похожие соображения применимы и к другим беспроводным средам. В работе [RFC5757] приведено краткое рассмотрение для сред 802.16 WiMAX, 3GPP/3GPP2, DVB-H/DVB-IPDC, а также широковещательного и спутникового телевидения.

7. Рекомендации

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

Следует применять прокси-методы для экономии пропускной способности сети и снижения расхода батарей в устройствах с энергосбережением. Устройства могут передавать индивидуальные сообщения своим прокси, а те будут заботиться о всех требуемых групповых операциях.

Групповую сигнализацию для беспроводных устройств следует выполнять с учётом снижения занятости процессоров.

8. Вопросы для обсуждения

В этом разделе предложены два вопроса для обсуждения в целях дальнейшего развития.

Во-первых, органам стандартизации (включая частные) следует создавать рекомендации, помогающие прояснить, когда лучше передавать групповые пакеты через кабельную, а не беспроводную сеть. Например, 802.1ak [IEEE802.1ak] работает с Ethernet и Wi-Fi, поэтому организации могут помочь в принятии решений о развёртывании, разработав рекомендации для групповой передачи через Wi-Fi, включая варианты передачи трафика по кабелям.

Во-вторых, надёжная регистрация в multicast-группах L2 и надёжные групповые операции L2 могут обеспечить хорошее решение для Wi-Fi. Не следует требовать поддержки 224 для групповой работы, достаточно просто выбрать число битов, имеющих смысл для данного размера сети, чтобы ограничить число нежелательных передач разумным уровнем. Рабочие группы IEEE 802.1, 802.11, 802.15 следует поощрять к пересмотру групповой передачи L2 и разработке работоспособных решений.

9. Вопросы безопасности

Этот документ не добавляет и не меняет механизмов защиты. Групповую передачу в кабельных и беспроводных сетях, рассматриваемую здесь, можно защитить разными способами. Например, в [RFC4601], описано применение IPsec для проверки подлинности сообщений на локальном канале (link-local) при независимой от протокола групповой маршрутизации (Protocol Independent Multicast – Sparse Mode или PIM-SM). В [RFC5796] заданы механизмы проверки подлинности локальных сообщений PIM-SM link-local с использованием IPsec ESP (Encapsulating Security Payload) или AH (Authentication Header).

При использовании механизмов преобразования группового трафика в индивидуальный для передачи по радиоканалам точка доступа AP (или иной объект) вынуждена явно отслеживать абонентов, заинтересованных в определённом групповом трафике. Обычно такой компромисс разумен, но но это ведёт к тому, что другой объект отслеживает подписчиков группового трафика. Хотя такая информация при необходимости где-то уже отслеживается, это расширяет фронт атак, при которых возможна утечка возможно конфиденциальных сведений.

Как отмечено в [group_key], ненадёжная по природе групповая передача через беспроводную среду может вызывать небольшие проблемы для управления и обновления групповых ключей. В [group_key] сказано, что при использовании шифрования TKIP (WPA сейчас не рекомендуется) или AES-CCMP (WPA2/WPA3) групповые пакеты от AP к клиентам (FromDS) должны шифроваться с использованием отдельного ключа, известного всем клиентам (Group Key). Далее там же сказано «… большинство клиентов могут подключаться и просматривать web0страницы, проверять почту и т. п., даже когда групповая передача FromDS не работает. Поэтому многие не осознают наличие проблем с групповой передачей в их сети …».

Этот документ рекомендует применять прокси-методы для экономии пропускной способности сети и снижения расхода батарей в устройствах с энергосбережением. С такими методами обычно связаны вопросы безопасности, требующие иметь доверенные прокси во избежание недопустимого поведения. Одним из таких методов является ARP Sponge, где прослушиваются запросы ARP и при наблюдении ARP для адреса IP, который считается неиспользуемым, прокси возвращает свой MAC-адрес. Отравление ARP (poisoning) и фальшивые анонсы могут нарушить (например, DoS) работу этого и других прокси-методов.

10. Взаимодействие с IANA

Этот документ не требует действий IANA.

11. Литература

[arpsponge] Wessel, M. and N. Sijm, “Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP Sponge”, July 2009, <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.182.4692>.

[bridge-mc-2-uc] “bridge: multicast to unicast”, commit 6db6f0e, January 2017, <https://github.com/torvalds/linux/commit/6db6f0e>.

[CAB] “limit multicast buffer hardware queue depth”, commit 2687951, June 2013, <https://patchwork.kernel.org/patch/2687951/>.

[Deri-2010] Deri, L. and J. Gasparakis, “10 Gbit Hardware Packet Filtering Using Commodity Network Adapters”, RIPE 61, November 2010, <http://ripe61.ripe.net/presentations/138-Deri_RIPE_61.pdf>.

[dot11] IEEE, “Information Technology–Telecommunications and Information Exchange between Systems – Local and Metropolitan Area Networks–Specific Requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications (includes 802.11v amendment)”, DOI 10.1109/IEEESTD.2021.9363693, IEEE Std 802.11-2020, December 2020, <https://standards.ieee.org/standard/802_11-2020.html>.

[dot11-proxyarp] Hiertz, G., Mestanov, F., and B. Hart, “Proxy ARP in 802.11ax”, September 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1015-01-00ax-proxy-arp-in-802-11ax.pptx>.

[dot11aa] IEEE, “Information technology–Telecommunications and information exchange between systems Local and metropolitan area networks–Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 2: MAC Enhancements for Robust Audio Video Streaming”, DOI 10.1109/IEEESTD.2012.6204193, IEEE Std 802.11aa-2012, March 2012, <https://standards.ieee.org/standard/802_11aa-2012.html>.

[group_key] “Subject: Why do some WiFi routers block multicast packets going from wired to wireless?”, message to the Super User Q & A community, January 2017, <https://superuser.com/questions/730288/why-do-some-wifi-routers-block-multicast-packets-going-from-wired-to-wireless>.

[IEEE802.1ak] IEEE, “Local and Metropolitan Area Networks Virtual Bridged Local Area Networks – Amendment 07: Multiple Registration Protocol”, DOI 10.1109/IEEESTD.2007.380667, IEEE Std 802.1ak-2007, June 2007, <https://www.ieee802.org/1/pages/802.1ak.html>.

[ietf_802-11] Stanley, D., “IEEE 802.11 multicast capabilities”, November 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1261-03-0arc-multicast-performance-optimization-features-overview-for-ietf-nov-2015.ppt>.

[mc-prob-stmt] Abrahamsson, M. and A. Stephens, “Multicast on 802.11”, 2013, <https://www.iab.org/wp-content/IAB-uploads/2013/01/multicast-problem-statement.pptx>.

[mc-props] Stephens, A., “IEEE 802.11 multicast properties”, September 2015, <https://mentor.ieee.org/802.11/dcn/15/11-15-1161-02-0arc-802-11-multicast-properties.ppt>.

[Oliva2013] de la Oliva, A., Serrano, P., Salvador, P., and A. Banchs, “Performance evaluation of the IEEE 802.11aa multicast mechanisms for video streaming”, 2013 IEEE 14th International Symposium on “A World of Wireless, Mobile and Multimedia Networks” (WoWMoM), pp. 1-9, DOI 10.1109/WoWMoM.2013.6583394, June 2013, <https://doi.org/10.1109/WoWMoM.2013.6583394>.

[RFC0826] Plummer, D., “An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware”, STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>.

[RFC2131] Droms, R., “Dynamic Host Configuration Protocol”, RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.

[RFC4286] Haberman, B. and J. Martin, “Multicast Router Discovery”, RFC 4286, DOI 10.17487/RFC4286, December 2005, <https://www.rfc-editor.org/info/rfc4286>.

[RFC4541] Christensen, M., Kimball, K., and F. Solensky, “Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches”, RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol Specification (Revised)”, RFC 4601, DOI 10.17487/RFC4601, August 2006, <https://www.rfc-editor.org/info/rfc4601>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6)”, RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration”, RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, “Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey”, RFC 5757, DOI 10.17487/RFC5757, February 2010, <https://www.rfc-editor.org/info/rfc5757>.

[RFC5796] Atwood, W., Islam, S., and M. Siami, “Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages”, RFC 5796, DOI 10.17487/RFC5796, March 2010, <https://www.rfc-editor.org/info/rfc5796>.

[RFC6282] Hui, J., Ed. and P. Thubert, “Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks”, RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.

[RFC6762] Cheshire, S. and M. Krochmal, “Multicast DNS”, RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.

[RFC6763] Cheshire, S. and M. Krochmal, “DNS-Based Service Discovery”, RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.

[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, “Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)”, RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.

[RFC6970] Boucadair, M., Penno, R., and D. Wing, “Universal Plug and Play (UPnP) Internet Gateway Device – Port Control Protocol Interworking Function (IGD-PCP IWF)”, RFC 6970, DOI 10.17487/RFC6970, July 2013, <https://www.rfc-editor.org/info/rfc6970>.

[RFC7450] Bumgardner, G., “Automatic Multicast Tunneling”, RFC 7450, DOI 10.17487/RFC7450, February 2015, <https://www.rfc-editor.org/info/rfc7450>.

[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, “Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol Specification (Revised)”, STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, “Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery”, RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.

[RFC8777] Holland, J., “DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery”, RFC 8777, DOI 10.17487/RFC8777, April 2020, <https://www.rfc-editor.org/info/rfc8777>.

[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, “IPv6 Backbone Router”, RFC 8929, DOI 10.17487/RFC8929, November 2020, <https://www.rfc-editor.org/info/rfc8929>.

[RFC9030] Thubert, P., Ed., “An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)”, RFC 9030, DOI 10.17487/RFC9030, May 2021, <https://www.rfc-editor.org/info/rfc9030>.

[Tramarin2017] Tramarin, F., Vitturi, S., and M. Luvisotto, “IEEE 802.11n for Distributed Measurement Systems”, 2017 IEEE International Instrumentation and Measurement Technology Conference (I2MTC), pp. 1-6, May 2017.

[uli] Kinney, P., “LLC Proposal for 802.15.4”, September 2015, <https://mentor.ieee.org/802.15/dcn/15/15-15-0521-01-wng0-llc-proposal-for-802-15-4.pptx>.

[v2011] IEEE, “Information technology — Local and metropolitan area networks — Specific requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 8: IEEE 802.11 Wireless Network Management”, DOI 10.1109/IEEESTD.2011.5716530, IEEE Std 802.11v-2011, February 2011, <https://ieeexplore.ieee.org/document/5716530>.

Благодарности

Этот документ выиграл в результате обсуждения с перечисленными в алфавитном порядке людьми: Mikael Abrahamsson, Bill Atwood, Stuart Cheshire, Donald Eastlake 3rd, Toerless Eckert, Jake Holland, Joel Jaeggli, Jan Komissar, David Lamparter, Morten Pedersen, Pascal Thubert, Jeffrey (Zhaohui) Zhang.

Адреса авторов

Charles E. Perkins
Lupin Lodge
Phone: +1 408 255 9223
Email: charliep@lupinlodge.com
 
Mike McBride
Futurewei Technologies Inc.
2330 Central Expressway
Santa Clara, CA 95055
United States of America
Email: michael.mcbride@futurewei.com
 
Dorothy Stanley
Hewlett Packard Enterprise
6280 America Center Dr.
San Jose, CA 95002
United States of America
Phone: +1 630 363 1389
Email: dorothy.stanley@hpe.com
 
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: warren@kumari.net
 
Juan Carlos Zúñiga
SIGFOX
Montreal
Canada
Email: j.c.zuniga@ieee.org

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

3Нажмите для разговора.

Рубрика: RFC | Оставить комментарий

RFC 9108 YANG Types for DNS Classes and Resource Record Types

image_print
Internet Engineering Task Force (IETF)                         L. Lhotka
Request for Comments: 9108                                        CZ.NIC
Category: Standards Track                                      P. Špaček
ISSN: 2070-1721                              Internet Systems Consortium
                                                          September 2021

YANG Types for DNS Classes and Resource Record Types

Типы YANG для классов DNS и типов RR

PDF

Аннотация

Этот документ вводит модуль YANG iana-dns-class-rr-type, содержащий производные типы данных, отражающие реестры IANA DNS CLASSes и Resource Record (RR) TYPEs. Эти типы YANG служат начальной основой для будущей работы по моделированию данных.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9108.

Авторские права

Авторские права (Copyright (c) 2021) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К этому документу относятся права и ограничения, указанные в в BCP 78 и IETF Trust Legal Provisions и применительно к документам IETF (http://trustee.ietf.org/license-info) на момент публикации данного документа. Прочтите эти документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML

1. Введение

Язык YANG [RFC7950] стал фактическим стандартом моделирования данных конфигурации и состояния, а также задания управляющих операций и асинхронных уведомлений. Разумно ожидать, что основанный на таких моделях данных подход вместе со стандартными протоколами управления, такими как NETCONF [RFC6241] и RESTCONF [RFC8040], можно будет эффективно применять и в операциях DNS. Фактически в настоящее время уже предпринимаются попытки использовать NETCONF и RESTCONF для настройки и управления:

  • полномочными серверами;

  • распознавателями;

  • данными зон.

Хотя можно использовать упомянутые протоколы управления со специализированными или частными (proprietary) моделями данных, их реальный потенциал может быть достигнут лишь при (полной или частичной) поддержке множеством программных реализаций DNS. Затем операторы смогут, например, запускать параллельно несколько реализаций сервера DNS и использовать общий интерфейс настройки и управления, а также данные всех этих серверов. Кроме того, значительно упростится переход на другую реализацию.

На основе опыта IETF Routing Area можно ожидать, что разработка унифицированных моделей данных для DNS окажется сложной и длительной и потребует активного сотрудничества и компромиссов между разработчиками и поставщиками основных серверных платформ DNS. Тем не менее, вполне вероятно, что любое моделирование относящихся к DNS данных потребует использования различных параметров и перечней DNS, заданных в нескольких реестрах IANA. Для использования с YANG эти параметры и перечни нужно перевести в соответствующие типы YANG или иные структуры. Такой трансляции следует быть простой и сравнительно бесспорной.

Этот документ обеспечивает трансляцию двух связанных с DNS фундаментальных реестров IANA в YANG. Документ содержит первоначальную версию модуля YANG iana-dns-class-rr-type, которая определяет производные типы для общих параметров записей DNS о ресурсах (RR) – класс и тип. Типы YANG dns-class и rr-type, отражают реестры IANA DNS CLASSes и Resource Record (RR) TYPEs [IANA-DNS-PARAMETERS].

В Приложении A приведена таблица стилей XSLT 1.0, предназначенная для использования IANA при генерации исходной версии модуля iana-dns-class-rr-type. Впоследствии при добавлении нового класса или типа RR в упомянутые реестры IANA будет также обновлять модуль iana-dns-class-rr-type, следуя инструкциям раздела 4.

2. Терминология

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Терминология для описания моделей данных YANG приведена в [RFC7950]. Используемые в документе термины DNS определены в [RFC1035] и [RFC8499].

3. Вопросы проектирования YANG

Во время написания этого документа реестр «Domain Name System (DNS) Parameters» [IANA-DNS-PARAMETERS] включал 13 субреестров. Модуль YANG iana-dns-class-rr-type определяет производные типы, соответствующие лишь 2 реестрам, которые важны для моделей данных, включающих данные зоны, а именно «DNS CLASSes» и «Resource Record (RR) TYPEs». Предполагается, что оставшиеся реестры [IANA-DNS-PARAMETERS], а также другие реестры IANA, связанные с DNS, по мере необходимости будут отражаться в последующих модулях YANG. Таким образом, можно будет выбрать подходящую комбинацию модулей YANG в зависимости от требуемых типов YANG и целей моделирования.

Реестры «DNS CLASSes» и «Resource Record (RR) TYPEs» преобразованы в перечисляемые типы YANG dns-class-name и rr-type-name, соответственно. Ниже приведён начальный фрагмент первого из них.

     typedef dns-class-name {
       type enumeration {
         enum IN {
           value 1;
           description
             "Internet (IN)";
           reference
             "RFC 1035";
         }
         ...
       }
       ...
     }

Другой производный тип rr-type-name определён аналогичным способом.

В [RFC3597] введена опция для указания класса или типа RR присвоенным ему десятичным номером вместо мнемонического имени. Например, класс IN можно указать как CLASS1, а тип AAAA – как TYPE28. В соответствии с этим производные типы dns-class и rr-type определены в модуле YANG как объединение двух типов:

  • 16-битовое десятичное значение (uint16);

  • мнемоническое имя, относящееся к перечисляемым типам dns-class-name и rr-type-name.

Например, тип rr-type определён как

     typedef rr-type {
       type union {
         type uint16;
         type rr-type-name;
       }
       description
         "Этот тип позволяет указывать тип записи о ресурсе DNS
          с использованием мнемонического имени или числа.";
     }

Поскольку для невыделенных и резервных классов и типов RR нет мнемонических имён, их можно указать лишь числами.

4. Взаимодействие с IANA

В этом разделе рассматриваются действия и процессы IANA, требуемые для поддержки модуля YANG iana-dns-class-rr-type, предназначенного для отображения реестров DNS CLASSes и Resource Record (RR) TYPEs [IANA-DNS-PARAMETERS]. Свежая версия модуля YANG доступна в реестре YANG Parameters [IANA-YANG-PARAMETERS].

С публикацией этого документа агентство IANA создало и разместило начальную версию модуля iana-dns-class-rr-type путём применения таблицы стилей XSLT из Приложения A к XML-версии [IANA-DNS-PARAMETERS].

Ниже приведено примечание, добавленное IANA к записи iana-dns-class-rr-type в реестре YANG Module Names [IANA-YANG-PARAMETERS].

Классы и типы записей о ресурсах DNS недопустимо добавлять напрямую в модуль YANG iana-dns-class-rr-type, они должны добавляться в реестры DNS CLASSes и Resource Record (RR) TYPEs, соответственно.

При добавлении класса DNS или типа RR в реестр DNS CLASSes или Resource Record (RR) TYPEs нужно добавлять оператор enum к типу dns-class-name или rr-type-name, соответственно. Имени в enum нужно совпадать с мнемоническим именем нового класса или типа. В оператор enum нужно включить указанные ниже субоператоры.

value

Десятичное значение из реестра.

status

Включается лишь для классов или типов, регистрация которых отменена или устарела. Значениям deprecated и obsolete в реестре соответствуют такие же значения в модуле YANG.

description

Копия соответствующих сведений из реестра, а именно полное имя нового класса DNS или значение нового типа RR, если оно имеется.

reference

Копия ссылок из реестра.

Невыделенные и резервные значение не нужно включать в перечисляемые типы dns-class-name и rr-type-name.

При каждом обновлении модуля YANG iana-dns-class-rr-type нужно добавлять новый оператор revision перед имеющимися операторами revision.

Ниже приведено примечание, добавленное IANA в реестры DNS CLASSes и Resource Record (RR) TYPEs.

При изменении реестра должен обновляться модуль YANG iana-dns-class-rr-type, как указано в [RFC9108].

Ниже приведено обновление текста Reference в реестре DNS CLASSes.

Старый текст

[RFC6895]

Новый текст

[RFC6895][RFC9108]

Ниже приведено обновление текста Reference в реестре Resource Record (RR) TYPEs.

Старый текст

[RFC6895][RFC1035]

Новый текст

[RFC6895][RFC1035][RFC9108]

4.1. Регистрация URI

Этот документ регистрирует URI в реестре IETF XML [RFC3688], добавляя в него приведённые ниже записи.

   URI:  urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace3.

4.2. Регистрация модуля YANG

Этот документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020], добавляя в него приведённые ниже записи.

   Name:  iana-dns-class-rr-type
   Namespace:  urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type
   Prefix:  dnsct
   Reference:  RFC 9108

5. Вопросы безопасности

Этот документ преобразует два реестра IANA в типы данных YANG и не задаёт новых технологий или протоколов. Определения сами по себе не влияют на безопасность Internet, но их применение в конкретных модулях YANG может оказывать такое влияние. Отмеченные в спецификации YANG [RFC7950] вопросы безопасности применимы и к этому документы.

6. Литература

6.1. Нормативные документы

[IANA-DNS-PARAMETERS] IANA, “Domain Name System (DNS) Parameters”, <https://www.iana.org/assignments/dns-parameters>.

[IANA-YANG-PARAMETERS] IANA, “YANG Parameters”, <https://www.iana.org/assignments/yang-parameters>.

[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>.

[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[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>.

[W3C.REC-xslt-19991116] Clark, J., “XSL Transformations (XSLT) Version 1.0”, W3C Recommendation REC-xslt-19991116, November 1999, <https://www.w3.org/TR/1999/REC-xslt-19991116>.

6.2. Дополнительная литература

[RFC1035] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC3597] Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types”, RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, “DNS Terminology”, BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.

Приложение A. Таблица стилей XSLT

В этом приложении содержится таблица стилей XSLT 1.0 [W3C.REC-xslt-19991116], использованная для создания исходной версии модуля YANG iana-dns-class-rr-type. Это было выполнено путём применения таблицы стилей к XML-версии реестра IANA Domain Name System (DNS) Parameters [IANA-DNS-PARAMETERS] на момент публикации этого документа.

С помощью программы xsltproc текст модуля YANG можно создать командой

       $ xsltproc iana-dns-class-rr-type.xsl dns-parameters.xml

   <CODE BEGINS> file "iana-dns-class-rr-type.xsl"
   <?xml version="1.0" standalone="yes"?>
   <stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
               xmlns:iana="http://www.iana.org/assignments"
               version="1.0">
     <output method="text"/>
     <strip-space elements="*"/>

     <variable name="dq">"</variable>
     <variable name="sq">'</variable>

     <variable name="module-intro">
       <text>module iana-dns-class-rr-type {
     yang-version 1.1;
     namespace
       "urn:ietf:params:xml:ns:yang:iana-dns-class-rr-type";
     prefix dnsct;

     organization
       "Internet Assigned Numbers Authority (IANA)";

     contact
       "        Internet Assigned Numbers Authority

        Postal: ICANN
                12025 Waterfront Drive, Suite 300
                Los Angeles, CA 90094

        Tel:    +1 424 254 5300

        &lt;mailto:iana@iana.org&gt;";

     description4
       "This YANG module translates IANA registries 'DNS CLASSes' and
        'Resource Record (RR) TYPEs' to YANG-derived types.

        Copyright (c) 2021 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module was generated from
        the corresponding IANA registries using an XSLT stylesheet
        from Appendix A of RFC 9108
        (https://www.rfc-editor.org/info/rfc9108); see the RFC itself
        for full legal notices.";

     reference
       "IANA 'Domain Name System (DNS) Parameters' registry
        https://www.iana.org/assignments/dns-parameters";</text>
        <text>&#xA;&#xA;</text>
     </variable>

     <template name="enum">
       <param name="id"/>
       <value-of select="concat('      enum ', $id)"/>
       <text> {&#xA;        value </text>
       <value-of select="concat(iana:value, ';&#xA;')"/>
       <if test="contains(iana:description, 'OBSOLETE')">
         <text>        status obsolete;&#xA;</text>
       </if>
       <apply-templates select="iana:description"/>
       <variable name="xrefs" select="iana:xref[@type!='note']"/>
       <if test="$xrefs">
         <text>        reference&#xA;          "</text>
         <if test="count($xrefs)&gt;1">- </if>
         <apply-templates select="iana:xref[@type!='note']"/>
       </if>
       <text>      }&#xA;</text>
     </template>

     <template match="/">
       <value-of select="$module-intro"/>
       <apply-templates select="iana:registry[@id='dns-parameters']"/>
       <text>}&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters']">
       <apply-templates select="iana:updated"/>
       <apply-templates
           select="iana:registry[@id='dns-parameters-2']"/>
       <apply-templates
           select="iana:registry[@id='dns-parameters-4']"/>
     </template>

     <template match="iana:updated">
       <value-of select="concat('  revision ', ., ' {')"/>
       <text>
       description
         "Initial revision.";
       reference
         "RFC 9108: YANG Types for DNS Classes and Resource Record
          Types";
     }

     /* Typedefs */&#xA;&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters-2']">
       <text>  typedef dns-class-name {&#xA;</text>
       <text>    type enumeration {&#xA;</text>
       <apply-templates
           select="iana:record[not(iana:description='Unassigned' or
                   starts-with(iana:description,'Reserved'))]"
           mode="class"/>
       <text>    }
       description5
         "This enumeration type defines mnemonic names and corresponding
          numeric values of DNS classes.";
       reference
         "RFC 6895: Domain Name System (DNS) IANA Considerations";
     }

     typedef dns-class {
       type union {
         type uint16;
         type dns-class-name;
       }
       description6
         "This type allows reference to a DNS class using either the
          assigned mnemonic name or numeric value.";
     }&#xA;&#xA;</text>
     </template>

     <template match="iana:registry[@id='dns-parameters-4']">
       <text>  typedef rr-type-name {&#xA;</text>
       <text>    type enumeration {&#xA;</text>
       <apply-templates
           select="iana:record[iana:type!='Unassigned' and
                   iana:type!='Private use' and iana:type!='Reserved']"
           mode="rr-type"/>
       <text>    }
       description7
         "This enumeration type defines mnemonic names and corresponding
          numeric values of DNS resource record types.";
       reference
         "- RFC 6895: Domain Name System (DNS) IANA Considerations

          - RFC 1035: Domain names - implementation and specification";
     }

     typedef rr-type {
       type union {
         type uint16;
         type rr-type-name;
       }
       description8
         "This type allows reference to a DNS resource record type
          using either the assigned mnemonic name or numeric value.";
     }&#xA;</text>
     </template>

     <template match="iana:record" mode="class">
       <call-template name="enum">
         <with-param name="id">
           <choose>
             <when test="contains(iana:description,'(')">
               <value-of select="substring-before(substring-after(
                                 iana:description, '('), ')')"/>
             </when>
             <otherwise>
               <value-of
                   select="substring-after(iana:description, ' ')"/>
             </otherwise>
           </choose>
         </with-param>
       </call-template>
     </template>

     <template match="iana:record" mode="rr-type">
       <call-template name="enum">
         <with-param name="id" select="iana:type"/>
       </call-template>
     </template>

     <template match="iana:description">
       <text>        description&#xA;          </text>
       <value-of select="concat($dq, ., $dq, ';&#xA;')"/>
     </template>

     <template match="iana:xref">
       <choose>
         <when test="@type='rfc'">
           <value-of
               select="concat('RFC ', substring-after(@data, 'rfc'))"/>
         </when>
         <when test="@type='person'">
           <apply-templates
               select="/iana:registry/iana:people/iana:person[
                       @id=current()/@data]"/>
         </when>
         <when test="@type='text'">
           <value-of select="translate(., $dq, $sq)"/>
         </when>
         <otherwise>
           <value-of select="@data"/>
         </otherwise>
       </choose>
       <choose>
         <when test="position()=last()">
           <text>";&#xA;</text>
         </when>
         <otherwise>
           <text>&#xA;           - </text>
         </otherwise>
       </choose>
     </template>

     <template match="iana:person">
       <value-of select="concat(iana:name, ' &lt;', iana:uri, '&gt;')"/>
     </template>

   </stylesheet>
   <CODE ENDS>

Адреса авторов

Ladislav Lhotka

CZ.NIC

Czech Republic

Email: ladislav.lhotka@nic.cz

Petr Špaček

Internet Systems Consortium

Czech Republic

Email: pspacek@isc.org


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Не задано. Запрошенный идентификатор URI является пространством имён XML.

4Этот модуль YANG транслирует реестры IANA «DNS CLASSes» и «Resource Record (RR) TYPEs» в типы YANG.

Авторские права (c) 2021 принадлежат IETF Trust и лицам, указанным как авторы кода. Все права защищены.

Распространение и использование в текстовой или двоичной форме с изменениями или без таковых может осуществляться на условиях Simplified BSD License, как указано в параграфе 4.c документа IETF Trust Legal Provisions применительно к документам IETF (https://trustee.ietf.org/license-info).

Эта версия модуля YANG создана из соответствующих реестров IANA с использованием таблицы стилей XSLT из Приложения A к RFC 9108 (https://www.rfc-editor.org/info/rfc9108). Полная юридическая информация приведена в самом RFC.

5Этот перечисляемый тип определяет мнемонические имена и соответствующие численные значения для классов DNS.

6Этот тип позволяет указывать классы DNS мнемоническим именем или числом.

7Этот перечисляемый тип определяет мнемонические имена и соответствующие численные значения для записей о ресурсах DNS.

8Этот тип позволяет указывать записи о ресурсах DNS мнемоническим именем или числом.

Рубрика: RFC | Оставить комментарий

RFC 9063 Host Identity Protocol Architecture

image_print
Internet Engineering Task Force (IETF)                 R. Moskowitz, Ed.
Request for Comments: 9063                                HTT Consulting
Obsoletes: 4423                                                  M. Komu
Category: Informational                                         Ericsson
ISSN: 2070-1721                                                July 2021

Host Identity Protocol Architecture

Архитектура протокола отождествления хостов

PDF

Аннотация

В этом документе описано пространство имён отождествления хостов (Host Identity), которое обеспечивает криптографическое пространство имён для приложений, протокол отождествления хоста (Host Identity Protocol или HIP), размещаемый между сетевым1 и транспортным уровнем, который поддерживает мобильность конечных хостов, многодомность и работу через NAT. В документе рассмотрены основы используемых в настоящее время пространств имён с их преимуществами и недостатками, а также их дополнение пространством HI. Определены роли пространства имён отождествления хостов в протоколах.

Этот документ отменяет RFC 4423 и решает проблемы, отмеченные IESG, в частности, вопрос гибкости шифрования. В разделе 11. Вопросы безопасности рассмотрены меры предотвращения лавинных атак (flooding), применение идентификаторов в списках контроля доступа, слабые типы идентификаторов и доверие при первом применении. Документ включает в себя уроки, извлечённые из реализации RFC 7401, и идёт дальше в разъяснении работы HIP как защищённого сигнального канала.

Статус документа

Документ относится к категории информационных и не задаёт стандартов Internet.

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9063.

Авторские права

Авторские права (Copyright (c) 2021) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Оглавление

Исключено в варианте HTML.

1. Введение

В Internet имеется два важных пространства имён – адреса IP и доменные имена DNS. Эти пространства включают набор функций и абстракций, обеспечивающих современное состояние Internet. Пространства также имеют ряд слабостей. По сути, эти пространства являются основой сети и мы пытаемся все делать в них. Семантическая перегрузка и функциональные расширения существенно усложнили эти пространства имён.

Предлагаемое пространство имён отождествления хостов также является глобальными занимает место между пространствами IP и DNS. Концептуально это пространство имён. относится к вычислительной платформе и такая платформа может иметь несколько идентификаторов (поскольку платформа может по разному идентифицировать себя разным партнёрам). Пространство имён. отождествления хостов состоит из идентификаторов хостов (Host Identifier или HI). Для каждого отождествления применяется в точности один идентификатор HI (хотя могут возникать переходные периоды, например, в момент замены ключей, когда могут быть активны несколько идентификаторов). Хотя далее в тексте обсуждаются некриптографические идентификаторы, архитектура фокусируется на криптографических идентификаторах хостов (HI). В частности, HI является открытым ключом асимметричной пары. Каждое отождествление хоста однозначно указывает один хост, т. е. два хоста не могут иметь совпадающие Host Identity. Если идентификаторы HI совпадают у двух или более вычислительных платформ, эти платформы являются экземплярами распределенного хоста. Идентификатор HI может быть публичным (например, доступным через DNS) или непубликуемым. В клиентских системах будут применяться оба типа HI.

Имеется незначительное но важное различие между отождествлением (Host Identity) и идентификатором (HI). Отождествление указывает абстрактную сущность, которая идентифицируется, а идентификатор – конкретную последовательность битов, используемую в процессе идентификации.

Хотя HI могут применяться во многих системах проверки подлинности (аутентификации), таких как IKEv2 [RFC7296], представленная архитектура задаёт новый протокол, названный протоколом отождествления хоста (Host Identity Protocol или HIP), и криптографический обмен, названный базовым обменом HIP (см. 6. Плоскость управления. HIP обеспечивает ограниченные варианты доверия между системами, повышает уровни мобильности, многодомности и динамической смены адресов IP, помогая в трансляции и изменении протоколов, а также снижая возможности организации некоторых DoS4-атак.

При использовании HIP фактический трафик данных между двумя хостами HIP обычно (но не обязательно) защищается с помощью ESP5 [RFC7402]. Отождествления хостов применяются для создания защищённых связей ESP (Security Association или SA) и аутентификации хостов. При использовании ESP фактические данные пакетов IP не отличаются от передаваемых в обычных пакетах IP с защитой ESP.

С момента публикации [RFC4423] было получено много информации о HIP [RFC6538]. Этот документ расширяет отождествление хоста за пределы первоначального применения для обеспечения связности IP и защиты, с целью предоставления общей защищённой сигнализации между хостами на уровне любого протокола. Сигналы могут организовать защищённую связь между хостами или просто передавать информацию внутри канала.

2. Терминология

2.1. Общие с другими документами термины

Таблица 1.

Термин

Определение

Public key
Открытый ключ

Открытый ключ асимметричной криптографической пары ключей. Применяется в качестве доступного идентификатора для криптографической проверки подлинности. Открытость в данном случае трактуется в диапазоне от «известно партнёру» до «известно всем».

Private key
Секретный ключ

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

Public key pair
Пара с открытым ключом

Асимметричная пара криптографических ключей, содержащая открытый и секретный ключ. Например, это может быть пара ключей Rivest-Shamir-Adleman (RSA), Digital Signature Algorithm (DSA), Elliptic Curve DSA (ECDSA).

Endpoint
Конечная точка

Взаимодействующая сущность (элемент). В силу исторических причин в этом документе в качестве (близкого) синонима используется термин «вычислительная платформа».

2.2. Термины, относящиеся к документам HIP

Следует отметить, что многие термины в этом документе являются тавтологическими, самоопределяющими или содержащими циклические ссылки на другие термины. Это связано с лаконичностью определений. Более подробные объяснения приведены в тексте документа и базовой спецификации [RFC7401].

Таблица 2.

Термин

Определение

Computing platform
Вычислительная платформа

Элемент, способный к взаимодействию и расчётам, например, компьютер. См. определение Endpoint выше.

HIP base exchange
Базовый обмен HIP

Криптографический протокол (см. также раздел 6).

HIP packet
Пакет HIP

Пакет IP, содержащий сообщение HIP.

Host Identity
Отождествление хоста

Абстрактная концепция, связанная с вычислительной платформе. См. Host Identifier ниже.

Host Identifier
Идентификатор хоста

Открытый ключ, служащий именем для отождествления хоста (Host Identity).

Host Identity namespace
Пространство имён отождествления хостов

Пространство имён, содержащее все возможные HI.

Host Identity Protocol
Протокол отождествления хоста

Протокол, используемый для передачи и аутентификации HI и другой информации.

Host Identity Hash
Хэш отождествления хоста

Криптографический хэш, применяемый для создания HIT из HI.

Host Identity Tag
Тег отождествления хоста

128-битовый блок данных, создаваемый применением криптографического хэширования к HI, с битами идентификации метода хэширования.

Local Scope Identifier
Локальный идентификатор

32-битовый блок данных, обозначающий отождествление хоста.

Public Host Identifier and Identity
Публичный идентификатор и отождествление хоста

Опубликованный или общедоступный идентификатор HI, служащий публичным именем для отождествления хоста, и соответствующее отождествление.

Unpublished Host Identifier and Identity
Неопубликованный идентификатор и отождествление хоста

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

Rendezvous Mechanism
Механизм встречи (рандеву)

Механизм, используемый для нахождения мобильных хостов по их HIT.

3. Основы

Тремя основными компонентами Internet являются вычислительные платформы (конечные системы), инфраструктура транспортировки пакетов (межсетевое взаимодействие) и службы (приложения). Internet служит для предоставления услуг людям и роботизированным системам («кремниевым людям», если угодно). Все упомянутые компоненты нужно именовать для обеспечения между ними расширяемого взаимодействия. В этом документе рассматривается именование вычислительных платформ и элементов доставки пакетов.

Для этих элементов (платформ) в Internet применяется два основных пространства имён – IP-адреса и доменные имена. Система доменных имён обеспечивает иерархическое выделение имён для некоторых вычислительных платформ и служб. Каждый уровень иерархии получает полномочия от вышележащего уровня и в доменных именах нет анонимности. Примерами доменных имён являются адреса Email, HTTP, SIP.

Пространство адресов IP перегружено их применением для интерфейсов (L3) и конечных точек (связанная с конечной точкой часть L3 и уровень L4). В части именования интерфейсов адреса IP иногда называют «локаторами» (locator) и они служат конечными точками в топологии маршрутизации.

IP-адреса являются числами, назначаемыми сетевым интерфейсам, и обычно применяются лишь при подключении интерфейса к сети. Изначально адреса IP служили для долгосрочной идентификации. Сегодня огромное число интерфейсов используют временные и/или неуникальные адреса IP, т. е. интерфейс получает адрес IP при подключении к сети.

В современной сети Internet транспортные уровни неразрывно связаны с адресами IP и не могут развиваться отдельно. На разработку IPng существенно повлиял отказ от создания соответствующего транспорта TCPng.

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

3.1. Пространство имён для вычислительных платформ

Независимое пространство имён для вычислительных платформ может применяться для сквозных (end-to-end) операций независимо от развития сетевого уровня и между разными сетевыми уровнями. Это позволит быстро менять адреса на сетевом уровне при перемещении, переносе или переадресации.

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

Ниже приведены характеристики пространства имён (для вычислительных платформ) и имён в них.

  • Пространство имён следует применять на уровне «ядра» или стека IP. Стек IP размещается между приложениями и инфраструктурой доставки пакетов.

  • Пространству следует полностью отделять (меж)сетевой уровень от вышележащих уровней. Именам следует заменять собой все вхождения адресов IP внутри приложений (как в блоке управления транспортом Transport Control Block или TCB). Замена может быть выполнена незаметно для унаследованных приложений с помощью локальных идентификаторов (Local Scope Identifier или LSI) и HIT, совместимых с адресами IPv4 и IPv6 [RFC5338]. Однако понимающие HIP приложения потребуется несколько изменить, например, в расширениях API для HIP [RFC6317].

  • Для введения пространства имён не следует требовать какой-либо административной инфраструктуры. Развёртывание должно выполняться снизу вверх попарно.

  • Для имён следует использовать представление фиксированного размера для простоты включения в заголовки дейтаграмм и имеющиеся программные интерфейсы (например, TCB).

  • Пространству имён следует быть доступным при использовании в протоколах. Это связано в основном с размером пакетов, а также вычислениями.

  • По возможности следует избегать конфликтов имён. Можно использовать математический «парадокс дней рождения» для оценки вероятности конфликта в данной популяции и хэш-пространстве. В общем случае для случайного хэш-пространства размером n битов конфликт предполагается после примерно 1,2*sqrt(2n) хэш-значений. Для 64 это составит около 4 миллиардов. Размер 64 бита может оказаться слишком малым для крупных популяций, например вероятность конфликта составит 1% для популяции 640M. Для 100 битов (или более) возникновение конфликта ожидается после расчёта 250 (1 квадриллион) значений. При используемом в настоящее время размере 96 битов [RFC7343] можно рассчитать без конфликтов 248 (281 триллион) значений.

  • Именам следует иметь локализованную абстракцию, чтобы их можно было применять в имеющихся протоколах и API.

  • Должна обеспечиваться возможность локального создания имён. Когда имена не публикуются, это может обеспечивать анонимность за счёт сложности предсказания.

  • Пространству имён следует поддерживать услуги проверки подлинности.

  • Именам следует быть долгоживущими, но с возможностью замены в любой момент. Это влияет на списки управления доступом – короткий срок действия повышает трудоёмкость поддержки списков или потребует в пространстве имён инфраструктуры для централизованного управления списками доступа.

В этом документе пространство имён, соответствующее приведённым выше характеристикам, называется пространством отождествления хостов – Host Identity. Использование идентификаторов HI требует своего протокольного уровня (Host Identity Protocol) между (меж)сетевым и транспортным уровнем. Имена создаются на основе криптографии с открытым ключом для предоставления услуг аутентификации. При корректной реализации можно обеспечить соответствие всем требованиям, приведённым выше.

4. Пространство имён отождествления хостов

Имя в пространстве Host Identity – идентификатор хоста (HI) представляет статистически уникальное значение для указания любой системы со стеком IP. Это отождествление обычно связано со стеком IP, но не ограничивается такой связью. Система может иметь множество идентификаторов, некоторые могут быть общеизвестными (well known), а другие – анонимными. Система может самостоятельно отождествлять себя или использовать сторонний аутентификатор, например DNSSEC [RFC4033], Pretty Good Privacy (PGP) или X.509 для «нотариального заверения» своего отождествления в другом пространстве имён.

Теоретически, любое имя, статистически уникальное в глобальном масштабе, может служить в качестве HI. В архитектуре HIP в качестве такого имени выбран открытый ключ пары асимметричных ключей, поскольку им можно управлять самостоятельно и такой ключ сложно подделать. Как указано в спецификации протокола HIP [RFC7401], HI на основе открытых ключей позволяет аутентифицировать пакеты HIP и защитить их от MitM6-атак. Поскольку аутентифицированные дейтаграммы обязательны для обеспечения основной защиты HIP от DoS-атак, обмен Diffie-Hellman в базовом обмене HIP использует аутентификацию. Таким образом, на практике поддерживаются лишь HI на базе открытых ключей и аутентифицированные сообщения HIP.

В этом документе упоминаются некриптографические формы HI и HIP, но следует предпочитать криптографические варианты, поскольку они более защищены. В прошлом исследовались варианты применения некриптографических HI для радио-меток (Radio Frequency IDentification или RFID) в обмене HIP, адаптированном для работы с такими задачами ([urien-rfid], [urien-rfid-draft]).

4.1. Идентификаторы хостов

Отождествление хостов добавляет в протоколы Internet два основных свойства. Первое заключается в развязывании (меж)сетевого и транспортного уровня (5. Новая архитектура стека), которое обеспечивает этим уровням возможность независимого развития, а также может обеспечить сквозные услуги через множество областей межсетевого взаимодействия. Вторым свойством является аутентификация хостов. Поскольку HI является открытым ключом, он может применяться для проверки подлинности в таких протоколах защиты как ESP.

Отождествление в HIP основано на парах из секретного и открытого ключа и представляется открытым ключом. Таким образом, имя, представляющее отождествление хоста в пространстве Host Identity, т. е. HI, является открытым ключом. В некотором смысле отождествление определяется владением секретным ключом. Если секретным ключом владеет несколько узлов, отождествление может считаться распределенным.

Архитектурно в качестве HI можно использовать любое другое соглашение от именовании в Internet, однако некриптографичекие имена следует применять лишь в средах с высоким уровнем доверия и/или малыми рисками. Это могут быть места, где не требуется аутентификация (нет риска подмены хоста) или не нужна защита ESP. Однако для соединённых между собой сетей, охватывающих несколько операционных доменов и сред, где существует риск подмены хостов, использование некриптографических HI вносит существенный риск. Поэтому в текущих документах HIP не задано использование HI, не основанных на открытых ключах. Например, служба Back to My Mac [RFC6281] от Apple очень близка по функциональности к HIP, но основана на некриптографических идентификаторах.

Реальные HI не применяются напрямую на транспортном или сетевом уровне. Соответствующие HI (открытые ключи) могут храниться в DNS или иных каталогах, как указано в этом документе, и могут передаваться в базовом обмене HIP. Другие протоколы применяют тег отождествления хоста (Host Identity Tag или HIT) для представления Host Identity. Другое представления отождествлений хостов – локальный идентификатор (Local Scope Identifier или LSI) также можно применять в протоколах и API.

4.2. Хэш отождествления хоста (HIH)

Хэш отождествления хоста (Host Identity Hash или HIH) – это криптографических алгоритм, служащий для создания HIT из HI, а также применяемый в HIP для простоты и единообразия. Два хоста в обмене HIP могут применять разные алгоритмы.

Требуется несколько HIH внутри HIP для решения вопросов создания перемещающихся целей и разрешения возможных конфликтов хэш-значений. Это существенно усложняет протокол HIP и ослабляет возможность атак на понижение в HIP [RFC7401].

4.3. Тег отождествления хоста (HIT)

Тег отождествления хоста (Host Identity Tag или HIT) – это 128-битовое представление Host Identity. Благодаря размеру, тег подходит для использования в имеющихся API сокетов вместо адреса IPv6 (например, sin6_addr в