RFC 9236 Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service

image_print
Internet Research Task Force (IRTF)                              J. Hong
Request for Comments: 9236                                        T. You
Category: Informational                                             ETRI
ISSN: 2070-1721                                                 V. Kafle
                                                                    NICT
                                                              April 2022

Architectural Considerations of Information-Centric Networking (ICN)
Using a Name Resolution Service

Архитектурные вопросы сетей ICN, использующих службы распознавания имён

PDF

Аннотация

В этом документе описаны архитектурные соображения, относящиеся к службе распознавания имён (Name Resolution Service или NRS) в ориентированных на информацию сетях (Information-Centric Networking или ICN). Документ разъясняет, как может меняться архитектура ICN при использовании NRS и как это использование влияет на систему маршрутизации ICN. Документ разработан исследовательской группой ICNRG (Information-Centric Networking Research Group).

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

Этот документ не содержит спецификации стандарта Internet (Standards Track) и публикуется с информационными целями.

Документ является результатом работы IRTF1. IRTF публикует результаты связанных Internet исследований и разработок. Эти результаты могут не подходить для развёртывания. Данный документ представляет согласованное мнение исследовательской группы Information-Centric Networking в составе IRTF. Документы, одобренные для публикации IRSG не являются кандидатами в какие-либо стандарты Internet (см. раздел 2 в RFC 7841).

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

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

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

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

Оглавление

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

1. Введение

Информационно-ориентированные сети (ICN) – это подход к развитию инфраструктуры Internet для обеспечения прямого доступа к именованным объектам (Named Data Object или NDO) по их именам. В двух распространённых архитектурах ICN – сети именованных данных (Named Data Networking или NDN) [NDN] и ориентированные на содержимое сети (Content-Centric Networking или CCNx) [CCNx] – имена NDO используются напрямую для маршрутизации запросов на извлечение объектов данных. Такая непосредственная маршрутизация по именам сталкивается с присущей ей по природе проблемами глобально расширяемой системы маршрутизации, обеспечением мобильности создателей (производителей) данных и поддержкой кэширования вне пути. Эти вопросы рассматриваются в разделе 3. Основы. Известны описания решений этих проблем с использованием системы распознавания имён (NRS), а также предложено несколько проектов ICN [Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] [Bayhan].

В этом документе рассматриваются возможные изменения архитектуры ICN, связанные с внедрением NRS, и влияние этого на систему маршрутизации ICN. Рассмотрены также архитектурные вопросы онтеграции ICN и NRS. Документ включает рассмотрение с точки зрения архитектуры ICN и системы маршрутизации при использовании NRS в сетях ICN. Описание самой системы NRS представлено в отдельном документе [RFC9138], где описаны подходы, функции и устройство NRS.

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

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

Name Resolution Service (NRS) – система распознавания имен

NRS в ICN определяется как служба, обеспечивающая функцию трансляции имён содержимого или объекта данных в некую информацию, такую как маршрутизируемый префикс, локатор, указатель на кэш вне пути или псевдоним имени, более подходящий, чем исходное имя, служащие для пересылки запроса объекта в направлении целевого получателя, хранящего NDO [RFC9138]. NRS, скорее всего, реализуется на основе распределенной базы данных с отображениями. В качестве NRS можно использовать систему доменных имён Domain Name System или DNS). Однако в этом случае необходимо учитывать требования частого обновления NRS в результате создания большого числа новых NDO и смены их местоположения в сети.

NRS server – сервер NRS

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

NRS resolver – распознаватель NRS

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

Name registration – регистрация имён

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

Name resolution – распознавание имён

Распознавание имён является основной функцией системы NRS. Оно выполняется распознавателями NRS, которые могут быть развёрнуты на узлах потребителей или маршрутизаторах ICN. Распознаватели отвечают за возврат кэшированной записи об отображении (срок действия таких записей ограничен) или передаёт запрос на распознавание в направлении сервера NRS. Сервер NRS выполняет поиск по имени содержимого в своей базе данных и в случае наличия записи извлекает её и возвращает в отклике на запрос распознавателю NRS.

NRS node – узел NRS

Серверы NRS называют также узлами NRS, поддерживающими записи об именах. Термины взаимозаменяемы.

NRS client – клиент NRS

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

3. Основы

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

Расширяемость маршрутизации

В ICN, имена приложений, указывающее содержимое, предназначены для использования напрямую при доставке пакетов, поэтому в маршрутизаторах ICN применяются протоколы маршрутизации по именам для создания таблиц маршрутизации и пересылки на основе имён. Как и в случае расширения маршрутизации IP, попадание неагрегируемых префиксов имён в зону без принятого по умолчанию маршрута (Default Route Free Zone или DFZ) маршрутизаторов ICN, вызывает неконтролируемый рост размера таблицы маршрутизации DFZ. Поэтому обеспечение некоторого уровня опосредованности за счёт внедрения NRS в ICN может обеспечить сохранение контроля над размером таблиц маршрутизации. Система NRS транслирует префиксы имён, отсутствующие в таблице пересылки DFZ, в глобально маршрутизируемые префиксы, такие как предложено в NDN [Afanasyev]. Другим решением проблемы расширяемости маршрутизации являются многоуровневые распределенные хэш-таблицы (Multi-level Distributed Hash Table или MDHT), применяемые в NetInf [Dannewitz]. Это обеспечивает anycast-маршрутизацию на основе имён, которая может поддерживать плоское (без иерархии) пространство имён и может быть приспособлена в глобальном масштабе [Dannewitz2].

Мобильность создателей содержимого

Если в ICN производитель содержимого перемещается в другую область (домен) имён, использующую иной префикс имён, запрос на созданное им содержимое по исходному его имени должен пересылаться в новое местоположение производителя содержимого. if a producer moves into a different name domain that uses a different name prefix, the request for a content produced by the moving producer with the origin content name must be forwarded to the moving producer’s new location. Поддержка мобильных создателей содержимого особенно усложняется в иерархической системе именования по сравнению с плоской схемой, поскольку требуется обновлять таблицы маршрутизации в более широкой области для отслеживания перемещений создателя содержимого. Поэтому в различных вариантах архитектуры ICN, таких как NetInf [Dannewitz] и MobilityFirst [MF], применяется система NRS для решения проблем при перемещении создателей содержимого.

Кэширование вне пути

Кэширование в сети является базовым свойством архитектуры ICN. Подход к кэшированию можно разделить на on-path (на пути) и off-path (вне пути) по местоположению кэша относительно пути пересылки от исходного хранилища содержимого к потребителю. Кэширование вне пути иногда называют репликацией или сохранением содержимого и оно нацелено на репликацию именованных объектов данных (NDO) в разных местах сети для повышения доступности содержимого и/или сокращения задержки при доступе. Кэш может располагать вне пути пересылки содержимого. Нахождение кэшированного вне пути содержимого требуется в системах маршрутизации исключительно на основе имён. Для поддержки доступа к кэшу вне пути местоположение реплик обычно анонсируется в систему маршрутизации по именам или в систему NRS, как описано в [Bayhan].

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

4. Влияние NRS на ICN

Система NRS не является обязательной частью архитектуры ICN, поскольку в большинстве ICN применяется маршрутизация по именам, не требующая процедуры распознавания имён. Поэтому добавление NRS в архитектуру ICN меняет некоторые аспекты по меньшей мере в части процедур рассылки, задержек и безопасности.

Процедура пересылки

При добавлении NRS в архитектуру ICN процедура распознавания имён включается в базовые архитектурные процедуры маршрутизации и пересылки ICN. Для интеграции NRS в архектуру ICN требуется решить ряд вопросов и указать, например, где, когда и как выполняется распознавание имён.

Задержка

Включение NRS в архитектуру ICN вносит дополнительную задержку, связанную с распознаванием, в систему маршрутизации и пересылки. Несмотря на добавление задержки из-за распознавания имён, общая задержка при обслуживании отдельных запросов может быть меньше, если процедура поиска NRS будет находить ближайшие копии расположенных вне пути кэшей. Кроме того, возможен благоприятный компромисс между задержкой на распознавание имён и снижением междоменного трафика за счёт нахождения ближайшей копии содержимого в кэше off-path. Нахождение ближайшего кэша с нужным содержимым может существенно сократить обнаружение содержимого и задержку при доставке.

Безопасность

Добавлении в архитектуру ICN системы NRS может расширить фронт атак. Защита самой NRS от распределенных атак на службы (Distributed Denial of Service или DDoS) и подмены или изменения отображений имён может оказаться сложной задачей.

5. Вопросы архитектуры ICN для NRS

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

5.1. Регистрация, распознавание и обновление записей для имён

При встраивании NRS а архитектуру ICN нужно рассмотреть функции, связанные с регистрацией, распознаванием и обновлением записей отображения имён. Узлы NRS поддерживают записи отображения имён и могут существовать в форме сети, наложенной на маршрутизаторы ICN, т. е. они взаимодействуют между собой через маршрутизаторы ICN. На рисунке 1 показаны узлы и клиенты NRS, связанные через базовую сеть. Узлы NRS следует развёртывать так, чтобы они всегда были доступны на небольшом удалении от клиентов NRS для снижения задержки при запросах регистрации и распознавания от клиентов NRS. Процедуры регистрации и распознавания имён, а также процедуры обновления записей для имён кратко рассматриваются ниже.

             +------------+             +------------+
             |  Узел NRS  |             |  Узел NRS  |
             +------------+             +------------+
                   |                          |
                   |                          |
+------------+     |                          |     +------------+
| Клиент NRS |--------------------------------------| Клиент NRS |
+------------+            Базовая сеть              +------------+

Рисунок 1. Узлы и клиенты NRS, соединённые через базовую сеть.


Регистрация имён

Регистрация имени выполняется создателем данных (клиент NRS). При создании нового содержимого и назначении ему имени из пространства префиксов имён создатель (издатель) выполняет регистрацию имени на узле NRS. Регистрацию можно выполнить на маршрутизаторе ICN, когда архитектура ICN поддерживает кэширование вне пути или совместное кэширование, поскольку вовлечение NRS может быть хорошей идеей для кэширования вне пути. Маршрутизаторы ICN с кэшем пересылки не требуют регистрации имён для кэшируемого содержимого, поскольку они находятся на пути пересылки в направлении, восходящем к хранилищу содержимого или издателю. К ним могут обращаться при пересылке будущих запросов издателю содержимого маршрутизаторами ICN на нисходящем пути к клиентскому узлу ICN. Однако маршрутизаторы ICN, выполняющие кэширование содержимого вне пути, могут вызывать процедуру регистрации имени, чтобы другие маршрутизаторы ICN могли полагаться при распознавании имён на сведения о местоположении кэшей, расположенных вне пути. Если содержимое кэшируется вне пути множеством маршрутизаторов ICN, все они могут регистрировать имена содержимого на одном узле NRS, что ведёт к множественным актам регистрации. В таких случаях узел NRS добавляет новое местоположение записи для имени к имеющимся местам. Таким способом каждая запись на узле NRS может указывать множество мест расположения содержимого. Назначение срока действия каждой записи об отображении может отдельно рассматриваться для кэширования содержимого вне пути и поддержки мобильности.

Распознавание имён

Распознавание имён выполняется клиентом NRS для получения записи об имени от узла NRS путём отправки сообщения с запросом распознавания и получения отклика с записью. В контексте маршрутизации ICN на основе имён распознавание требуется на каждом маршрутизаторе ICN, чья база данных о пересылке (forwarding information base или FIB) не содержит префикса запрошенного имени. Распознавание имён может также выполняться потребителем (особенно многодомным) для пересылки запросов содержимого в более подходящем направлении, чтобы получить содержимое из ближайшего кэша. Если потребитель имеет одно подключение, он может не утруждать себя распознаванием имён, полагаясь на прямую маршрутизацию по именам или распознавание имён восходящим маршрутизатором ICN. В этом случае потребитель создаёт пакет запроса содержимого, включающий имя, и направляет этот пакет ближайшему маршрутизатору ICN. Маршрутизатор ICN просматривает свою таблицу FIB для пересылки запроса содержимого. Если маршрутизатор ICN не может определить доступность запрошенного содержимого, он выполняет распознавание имени для получения записи об отображении имени и добавляет эту запись в свою FIB. Маршрутизатор ICN может выполнять распознавание имени даже до получения запроса содержимого, чтобы использовать запись об отображении в своей таблице FIB.

Обновление записей для имён

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

5.2. Протоколы и семантика

Для развёртывания системы NRS в локальном или глобальном домене сети ICN нужны новые протоколы и семантика, разработанные и реализованные для поддержки и распознавания имён в разных пространствах имён.

Одним из способов реализации NRS для CCNx является расширение базового формата TLV и семантики [RFC8569] [RFC8609]. Например, запросы и отклики распознавания имён можно реализовать путём определения новых типов полей в сообщениях Interest и Content Object [CCNxNRS]. Используя имеющиеся пакеты CCNx Interest и Content Object для регистрации и распознавания имён, систему NRS можно развернуть с незначительными изменениями протоколов ICN. Однако в таких случаях система NRS может быть неспособной использовать более гибкие и расширяемые схемы.

С другой стороны, система NRS может быть разработана независимо ко своими протоколами и семантикой, подобно NRS, описанной в [Hong]. Например, протокол и сообщения NRS можно реализовать с использованием RESTful API, а NRS может работать как прикладной протокол, независимый от остальных протоколов ICN.

5.3. Система маршрутизации

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

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

Сведения, полученные при распознавании имён, могут не иметь фору имени. Например, они могут указывать IP-адрес конечной точки туннеля, чрез которую пересылается запрос содержимого.

6. Заключение

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

В документе определено несколько терминов, связанных с NRS, и разъяснены некоторые проблемы, присущие маршрутизации ICN на основе лишь имён, такие как расширяемость маршрутизации, мобильность издателей, кэширование вне пути. Документ описывает изменения архитектуры ICN в части процедур, задержек и безопасности при использовании NRS. В соответствии с изменениями архитектуры ICN документ рассматривает архитектурные соображения ICN для NRS, такие как функции, связанные с регистрацией, распознаванием и обновлением записей об отображении имён, протоколами и семантикой для реализации системы NRS, а также вовлечением системы маршрутизации в распознавание имён.

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

Этот документ не требует действий IANA.

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

При внесении в архитектуру ICN новых компонент, таких как NRS, фронт атак расширяется. Связанные с этим вопросы безопасности рассмотрены ниже.

Безопасность пространств имён

Для развёртывания системы NRS в архитектуре ICN пространства имён ICN, которые могут выделяться уполномоченными элементами, должны защищённо отображаться на издателей содержимого и надёжно обслуживаться теми. Согласно исследованиям ICN [RFC7927], новое пространство имён может также обеспечивать функцию проверки целостности для контроля подлинности издателей. Вопросы аутентификации пространства имён и отображений между разными пространствами имён требуют дополнительного исследования.

Безопасность системы NRS

NRS требует развёртывания новых элементов (например, серверов NRS) для создания распределенных и расширяемых систем NRS. Такие элементы, например, серверы NRS, могут подвергаться атакам с использованием ложных запросов от бесчисленных злоумышленников, включая атаки на отказ в обслуживании (DoS и DDoS). Кроме того, клиенты NRS обычно должны в некоторой степени доверять серверам NRS из других доменов сети, а обмен данными в этих случаях должен быть надёжно защищён от вредоносных воздействий. Историю данных распознавания имён требуется хранить и анализировать как в пассивных DNS для выявления возможных инцидентов безопасности и обнаружения вредоносных инфраструктур.

Безопасность протокола и сообщений NRS

В системе NRS протоколы для создания, передачи и приёма сообщений NRS, связанных с регистрацией, распознаванием и обновлением записей для имён, следует защищать с помощью подходящих механизмов. Должны обеспечиваться подобающие меры защиты, чтобы инициировать и читать сообщения NRS могли только легитимные узлы. Целостность этих сообщений должна защищаться, а также должны применяться механизмы проверки подлинности, чтобы неуполномоченные стороны не могли манипулировать сообщениями при пересылке через сеть. Следует также предусматривать механизмы шифрования сообщений, чтобы предотвратить утечки данных и нарушения конфиденциальности. Множество проблем, аналогичных известным для сетей IP и DNS, могут оказывать влияние на архитектуру ICN в целом. Подход с минимизацией DNS QNAME может оказаться подходящим для обеспечения безопасности процессов распознавания имён. Следует предусматривать механизмы защиты, такие как проверка подлинности при доступе и т. п. для систем NRS [RFC9138], обеспечивающие безопасность не только NRS но и всей архитектуры ICN.

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

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

[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, “Information-Centric Networking (ICN) Research Challenges”, RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.

[RFC8569] Mosko, M., Solis, I., and C. Wood, “Content-Centric Networking (CCNx) Semantics”, RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.

[RFC8609] Mosko, M., Solis, I., and C. Wood, “Content-Centric Networking (CCNx) Messages in TLV Format”, RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.

[RFC9138] Hong, J., You, T., Dong, L., Westphal, C., and B. Ohlman, “Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)”, RFC 9138, DOI 10.17487/RFC9138, December 2021, <https://www.rfc-editor.org/info/rfc9138>.

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

[Afanasyev] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, “SNAMP: Secure namespace mapping to scale NDN forwarding”, 2015 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2015.7179398, April 2015, <https://doi.org/10.1109/INFCOMW.2015.7179398>.

[Bayhan] Bayhan, S., Ott, J., Kangasharju, J., Sathiaseelan, A., and J. Crowcroft, “On Content Indexing for Off-Path Caching in Information-Centric Networks”, ACM ICN, DOI 10.1145/2984356.2984372, September 2016, <https://doi.org/10.1145/2984356.2984372>.

[CCNx] “Cicn”, <https://wiki.fd.io/view/Cicn>.

[CCNxNRS] Hong, J., You, T., and Y. Hong, “CCNx Extension for Name Resolution Service”, Work in Progress, Internet-Draft, draft-hong-icnrg-ccnx-nrs-02, 2 July 2018, <https://datatracker.ietf.org/doc/html/draft-hong-icnrg-ccnx-nrs-02>.

[Dannewitz] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and H. Karl, “Network of Information (NetInf) – An information-centric networking architecture”, Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.009>.

[Dannewitz2] Dannewitz, C., D’Ambrosio, M., and V. Vercellone, “Hierarchical DHT-based name resolution for information-centric networks”, Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.014, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.014>.

[Hong] Hong, J., Chun, W., and H. Jung, “Demonstrating a Scalable Name Resolution System for Information-Centric Networking”, ACM ICN, DOI 10.1145/2810156.2812617, September 2015, <https://doi.org/10.1145/2810156.2812617>.

[MF] Future Internet Architecture (FIA), “MobilityFirst”, <http://mobilityfirst.cs.umass.edu/>.

[NDN] NDN, “Named Data Networking”, September 2010, <https://www.named-data.net>.

[Ravindran] Ravindran, R., Chakraborti, A., and A. Azgin, “Forwarding Label support in CCN Protocol”, Work in Progress, Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02>.

[SAIL] “Scalable and Adaptive Internet Solutions (SAIL)”, <https://www.sail-project.eu/>.

[Zhang2] Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, “A Survey of Mobility Support in Named Data Networking”, Named Data Networking, Workshop on Name-Oriented Mobility: Architecture, Algorithms and Applications (NOM), April 2016.

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

Авторы признательны Dave Oran (сопредседатель ICNRG) за очень полезные рецензии и комментарии, которые помогли значительно улучшить этот документ.

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

Jungha Hong
ETRI
Yuseung-Gu
218 Gajeong-ro
Daejeon
34129
Republic of Korea
Email: jhong@etri.re.kr
 
Tae-Wan You
ETRI
Yuseung-Gu
218 Gajeong-ro
Daejeon
34129
Republic of Korea
Email: twyou@etri.re.kr
 
Ved Kafle
NICT
Koganei
4-2-1 Nukui-Kitamachi, Tokyo
184-8795
Japan
Email: kafle@nict.go.jp

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

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

nmalykh@protokols.ru


1Internet Research Task Force – комиссия по исследованиям Internet.

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

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

Linux BPF

image_print

Linux BPF

PDF

Фильтрация сокетов в Linux или пакетный фильтр Беркли (Berkeley Packet Filter или BPF). На основе перевода документа Documentation/networking/filter.rst из состава исходных кодов ядра Linux.

Введение

Фильтрация сокетов Linux (Linux Socket Filtering или LSF) основана на пакетных фильтрах Беркли. Несмотря на множество различий между фильтрацией в ядре BSD и Linux, при обсуждении BPF или LSF в контексте Linux рассматриваются практически те же механизмы фильтрации в ядре Linux.

BPF позволяет программам пользовательского пространства присоединять фильтры к любому сокету и разрешать или запрещать прохождение некоторых типов данных через сокет. LSF применяет такую же структуру кода фильтрации, что используется BPF в BSD, поэтому полезно прочесть руководство (man) BSD bpf.4 для работы с фильтрами.

В Linux фильтрация BPF существенно проще, чем в BSD – здесь не нужно беспокоиться об устройствах и других вещах. Нужно просто создать код своего фильтра, передать его ядру через опцию SO_ATTACH_FILTER и после успешной проверки кода ядром сразу же начнётся фильтрация данных на сокете. Фильтры сокетов можно отсоединять с помощью опции SO_DETACH_FILTER. Вероятно эта возможность не будет применяться часто, поскольку при закрытии сокета фильтры удаляются автоматически. Другим менее распространенным случаем является добавление другого фильтра на сокете, где фильтр уже работает. В этом случае ядро будет удалять прежний фильтр и устанавливать новый, если тот прошёл проверку. При отказе в процессе проверки на сокете сохранится прежний фильтр.

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

Основным пользователем этих конструкций является библиотека libpcap. Используя команды вида tcpdump -i em1 port 22, передаваемые через внутренний компилятор libpcap, который создаёт структуру, передаваемую в конечном итоге ядру через SO_ATTACH_FILTER, библиотека может устанавливать нужные фильтры.

Хотя здесь упоминались лишь сокеты, BPF в Linux применяется и во многих других местах. Это включает xt_bpf для netfilter, cls_bpf на уровне qdisc в ядре, SECCOMP-BPF (SECure COMPuting [1]) и пр.

Структура

Приложения пользовательского уровня включают файл <linux/filter.h>, содержащий указанную ниже структуру.

	struct sock_filter {	/* Блок фильтра */
		__u16	code;	/* Фактический код фильтрации */
		__u8	jt;	/* Переход при совпадении */
		__u8	jf;	/* Переход при несовпадении */
		__u32	k;	/* Базовое многоцелевое поле */
	};

Такая структура организуется в форме массива квартетов (4-tuple) в форме (code, jt, jf, k). Поля jt и jf задают смещение для перехода, а k указывает базовое значение для использования представленным ниже кодом.

	struct sock_fprog {		/* Требуется для SO_ATTACH_FILTER. */
		unsigned short len;	/* Число блоков фильтра */
		struct sock_filter __user *filter;
	};

Для фильтрации на сокете указатель на эту структуру (см. Пример) передаётся ядру через setsockopt().

Пример

    #include <sys/socket.h>
    #include <sys/types.h>
    #include <arpa/inet.h>
    #include <linux/if_ether.h>
    /* ... */

    /* Для упомянутой выше команды tcpdump -i em1 port 22 -dd */
    struct sock_filter code[] = {
	    { 0x28,  0,  0, 0x0000000c },
	    { 0x15,  0,  8, 0x000086dd },
	    { 0x30,  0,  0, 0x00000014 },
	    { 0x15,  2,  0, 0x00000084 },
	    { 0x15,  1,  0, 0x00000006 },
	    { 0x15,  0, 17, 0x00000011 },
	    { 0x28,  0,  0, 0x00000036 },
	    { 0x15, 14,  0, 0x00000016 },
	    { 0x28,  0,  0, 0x00000038 },
	    { 0x15, 12, 13, 0x00000016 },
	    { 0x15,  0, 12, 0x00000800 },
	    { 0x30,  0,  0, 0x00000017 },
	    { 0x15,  2,  0, 0x00000084 },
	    { 0x15,  1,  0, 0x00000006 },
	    { 0x15,  0,  8, 0x00000011 },
	    { 0x28,  0,  0, 0x00000014 },
	    { 0x45,  6,  0, 0x00001fff },
	    { 0xb1,  0,  0, 0x0000000e },
	    { 0x48,  0,  0, 0x0000000e },
	    { 0x15,  2,  0, 0x00000016 },
	    { 0x48,  0,  0, 0x00000010 },
	    { 0x15,  0,  1, 0x00000016 },
	    { 0x06,  0,  0, 0x0000ffff },
	    { 0x06,  0,  0, 0x00000000 },
    };

    struct sock_fprog bpf = {
	    .len = ARRAY_SIZE(code),
	    .filter = code,
    };

    sock = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
    if (sock < 0)
	    /* ... код ... */

    ret = setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, &bpf, sizeof(bpf));
    if (ret < 0)
	    /* ... код ... */

    /* ... */
    close(sock);

Приведённый выше код присоединяет фильтр к сокету PF_PACKET для отбора всех пакетов IPv4 и IPv6, направленных в порт 22. Остальные пакеты сокет будет отбрасывать.

Вызову setsockopt() для SO_DETACH_FILTER не требуется аргументов, а SO_LOCK_FILTER для блокировки фильтра принимает целое число 0 или 1.

Отметим, что фильтры могут применяться не только для сокетов PF_PACKET, но и для сокетов иных семейств.

Сводка системных вызовов приведена ниже

setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &val, sizeof(val));
setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &val, sizeof(val));
setsockopt(sockfd, SOL_SOCKET, SO_LOCK_FILTER,   &val, sizeof(val));

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

В указанных ниже случаях могут применяться «написанные вручную» фильтры:

  1. применение libpcap не рассматривается (невозможно);

  2. требуемые фильтры BPF должны использовать расширения, не поддерживаемые компилятором libpcap;

  3. фильтр слишком сложен и его поддержка компилятором libpcap не очевидна;

  4. код конкретного фильтра следует оптимизировать не так, как это делает встроенный компилятор libpcap.

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

Машина и набор инструкций BPF

В bpf имеется инструмент bpf_asm, который можно применять для написания низкоуровневых фильтров, подобных описанным выше. Похожий на ассемблер синтаксис bpf_asm ниже используется в описаниях вместо явных кодов операций. Этот синтаксис очень похож на применяемый в статье Steven McCanne т Van Jacobson о фильтрах BPF [2].

Базовые элементы архитектуры BPF приведены в таблице.

Элемент

Описание

A

Аккумулятор (накопитель) размером 32 бита.

XX

Регистр X размером 32 бита.

M[]

Массив из 16 регистров (от 0 до 15) по 32 бита или хранилище в памяти (scratch memory store).

Программа, транслируемая bpf_asm в коды операций (opcode), представляет собой массив упомянутых элементов

  op:16, jt:8, jf:8, k:32

Элемент op является 16-битовым кодом операции, задающим конкретную инструкцию (команду). Элементы jt и jf являются 8-битовыми словами, указывающими адрес перехода для совпадения (true) и несовпадения (false), соответственно. Элемент k содержит аргумент, интерпретация которого зависит от операции op.

Набор инструкций (команд) включает команды загрузки (load), записи (store), ветвления (branch), арифметических операций (alu), копирования и возврата управления (return), которые представлены также в синтаксисе bpf_asm. В таблице указаны все доступные команды bpf_asm с указанием операций, заданных в файле linux/filter.h.

Инструкция

Режим адресации

Описание

Команды загрузки

ld

1, 2, 3, 4, 12

Загрузка слова в A

ldi

4

Загрузка слова в A

ldh

1, 2

Загрузка полуслова в A

ldb

1, 2

Загрузка байта в A

ldx

3, 4, 5, 12

Загрузка слова в X

ldxi

4

Загрузка слова в X

ldxb

5

Загрузка байта в X

Команды записи

st

3

Запись (сохранение) A в M[]

stx

3

Запись (сохранение) X в M[]

Команды перехода

jmp

6

Переход к метке

ja

6

Переход к метке

jeq

7, 8, 9, 10

Переход при A == <x>

jneq

9, 10

Переход при A != <x>

jne

9, 10

Переход при A != <x>

jlt

9, 10

Переход при A < <x>

jle

9, 10

Переход при A <= <x>

jgt

7, 8, 9, 10

Переход при A > <x>

jge

7, 8, 9, 10

Переход при A >= <x>

jset

7, 8, 9, 10

Переход при A & <x>

Арифметические операции

add

0, 4

A + <x>

sub

0, 4

A – <x>

mul

0, 4

A * <x>

div

0, 4

A / <x>

mod

0, 4

A % <x>

neg

!A

and

0, 4

& <x>

or

0, 4

A | <x>

xor

0, 4

A ^ <x>

lsh

0, 4

A << <x>

rsh

0, 4

A >> <x>

Команды копирования

tax

Копирование A в X

txa

Копирование X в A

Команда возврата

ret

4, 11

Возврат управления

В следующей таблице указаны режимы адресации (второй столбец предыдущей таблицы).

Режим

Синтаксис

Описание

0

x/%x

Регистр X

1

[k]

Двоичное полуслово (BHW) с байтовым смещением k в пакете

2

[x + k]

Двоичное полуслово (BHW) со смещением X + k в пакете

3

M[k]

Слово со смещением k в массиве M[]

4

#k

Литеральное значение, хранящееся в k

5

4*([k]&0xf)

Младший полубайт (nibble) * 4 в байте со смещением k в пакете

6

L

Переход к метке L

7

#k,Lt,Lf

Переход к метке Lt при совпадении (true), иначе переход к Lf

8

x/%x,Lt,Lf

Переход к метке Lt при совпадении (true), иначе переход к Lf

9

#k,Lt

Переход к Lt, если утверждение (predicate) верно (true)

10

x/%x,Lt

Переход к Lt, если утверждение (predicate) верно (true)

11

a/%a

Аккумулятор A

12

расширение

Расширение BPF

Ядро Linux включает расширения BPF, применяемые с командами загрузки, путём указания аргумента k с отрицательным смещением и смещением конкретного расширения. Результат таких расширений BPF загружается в A. Возможные расширения BPF показаны в таблице.

Расширение

Описание

len

skb->len

proto

skb->protocol

type

skb->pkt_type

poff

Смещение начала данных (payload)

ifidx

skb->dev->ifindex

nla

Атрибут netlink типа X со смещением A

nlan

Вложенный атрибут netlink типа X со смещением A

mark

skb->mark

queue

skb->queue_mapping

hatype

skb->dev->type

rxhash

skb->hash

cpu

raw_smp_processor_id()

vlan_tci

skb_vlan_tag_get(skb)

vlan_avail

skb_vlan_tag_present(skb)

vlan_tpid

skb->vlan_proto

rand

prandom_u32()

Эти расширения могут также включать префикс #.

Примеры низкоуровневых BPF

Пакеты ARP
  ldh [12]
  jne #0x806, drop
  ret #-1
  drop: ret #0
Пакеты IPv4 TCP
  ldh [12]
  jne #0x800, drop
  ldb [23]
  jneq #6, drop
  ret #-1
  drop: ret #0
Выборка случайного пакета ICMP, 1 из 4
  ldh [12]
  jne #0x800, drop
  ldb [23]
  jneq #1, drop
  # Получение случайного значения uint32
  ld rand
  mod #4
  jneq #1, drop
  ret #-1
  drop: ret #0
Пример фильтра SECCOMP
  ld [4]                  /* offsetof(struct seccomp_data, arch) */
  jne #0xc000003e, bad    /* AUDIT_ARCH_X86_64 */
  ld [0]                  /* offsetof(struct seccomp_data, nr) */
  jeq #15, good           /* __NR_rt_sigreturn */
  jeq #231, good          /* __NR_exit_group */
  jeq #60, good           /* __NR_exit */
  jeq #0, good            /* __NR_read */
  jeq #1, good            /* __NR_write */
  jeq #5, good            /* __NR_fstat */
  jeq #9, good            /* __NR_mmap */
  jeq #14, good           /* __NR_rt_sigprocmask */
  jeq #13, good           /* __NR_rt_sigaction */
  jeq #35, good           /* __NR_nanosleep */
  bad: ret #0             /* SECCOMP_RET_KILL_THREAD */
  good: ret #0x7fff0000   /* SECCOMP_RET_ALLOW */

Примеры низкоуровневых расширений BPF

Пакет для интерфейса с индексом 13
  ld ifidx
  jneq #13, drop
  ret #-1
  drop: ret #0
VLAN с идентификатором 10
  ld vlan_tci
  jneq #10, drop
  ret #-1
  drop: ret #0

Приведённые выше примеры кода можно поместить в файл (здесь назван foo) и затем передать bpf_asm для генерации кодов операций, которые будут понятны xt_bpf и cls_bpf и могут загружаться в них напрямую. Например, для указанного выше фильтра ARP результат будет иметь вид

    $ ./bpf_asm foo
    4,40 0 0 12,21 0 1 2054,6 0 0 4294967295,6 0 0 0,

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

    $ ./bpf_asm -c foo
    { 0x28,  0,  0, 0x0000000c },
    { 0x15,  0,  1, 0x00000806 },
    { 0x06,  0,  0, 0xffffffff },
    { 0x06,  0,  0, 0000000000 },

В частности, поскольку применение с xt_bpf или cls_bpf может приводить к более сложным фильтрам BPF, которые поначалу могут казаться неочевидными, рекомендуется тестировать фильтры перед их установкой в работающей системе. Для этого служит простой инструмент bpf_dbg, исходный код которого помещён в каталог tools/bpf/ исходных кодов ядра. Этот отладчик позволяет протестировать фильтры BPF на указанных файлах pcap, организовать пошаговое выполнение кода BPF на файлах pcap и получить содержимое регистров машины BPF.

Для запуска отладчика bpf_dbg служит команда

    # ./bpf_dbg

Если ввод и вывод отличается от стандартного (stdin, stdout), bpf_dbg принимает замену stdin в качестве первого аргумента и stdout – в качестве второго. Например, ./bpf_dbg test_in.txt test_out.txt. Кроме того, можно задать конфигурацию libreadline в файле ~/.bpf_dbg_init, а история команд сохраняется в файле ~/.bpf_dbg_history.

Взаимодействие в bpf_dbg происходит через командный процессор (shell), поддерживающий дополнение команд. В приведённых ниже примерах команды вводятся из оболочки bpf_dbg. Примеры работы приведены ниже.

load bpf 6,40 0 0 12,21 0 3 2048,48 0 0 23,21 0 1 1,6 0 0 65535,6 0 0 0

Фильтр BPF загружается из стандартного вывода bpf_asm или преобразуется из команды, например, “tcpdump -iem1 -ddd port 22 | tr ‘\n’ ‘,’“. Отметим, что для отладки JIT (Компилятор JIT) эта команда создаёт временный сокет и загружает код BPF в ядро, поэтому она будет полезна и для разработчиков JIT.

load pcap foo.pcap

Загрузка стандартного файла tcpdump pcap.

run [<n>]

bpf passes:1 fails:9

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

disassemble::

l0:	ldh [12]
l1:	jeq #0x800, l2, l5
l2:	ldb [23]
l3:	jeq #0x1, l4, l5
l4:	ret #0xffff
l5:	ret #0

Выводит дизассемблированный код BPF.

dump::

/* { op, jt, jf, k }, */
{ 0x28,  0,  0, 0x0000000c },
{ 0x15,  0,  3, 0x00000800 },
{ 0x30,  0,  0, 0x00000017 },
{ 0x15,  0,  1, 0x00000001 },
{ 0x06,  0,  0, 0x0000ffff },
{ 0x06,  0,  0, 0000000000 },

Выводит дамп кода BPF в стиле C.

breakpoint 0::

breakpoint at: l0: ldh [12]

breakpoint 1::

breakpoint at: l1: jeq #0x800, l2, l5

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

run::

-- register dump --
pc:       [0]                       <-- счётчик команд
code:     [40] jt[0] jf[0] k[12]    <-- код BPF для текущей инструкции
curr:     l0:	ldh [12]             <-- дизассемблированная текущая инструкция
A:        [00000000][0]             <-- содержимое A (hex, decimal)
X:        [00000000][0]             <-- содержимое X (hex, decimal)
M[0,15]:  [00000000][0]             <-- содержимое M (hex, decimal)
-- packet dump --                   <-- текущий пакет от pcap (hex)
len: 42
    0: 00 19 cb 55 55 a4 00 14 a4 43 78 69 08 06 00 01
16: 08 00 06 04 00 01 00 14 a4 43 78 69 0a 3b 01 26
32: 00 00 00 00 00 00 0a 3b 01 01
(breakpoint)
>

breakpoint::

breakpoints: 0 1

Выводит список установленных точек прерывания.

step [-<n>, +<n>]

Пошаговое выполнение программы BPF от текущего смещения. При каждом вызове step выводится показанный выше дамп регистров. Исполнение может происходить также в прямом и обратном направлении.

select <n>

Выбирает заданный пакет из файла pcap для работы с ним. При следующем вызова run или step программа BPF будет обрабатывать заданный пользователем пакет. Нумерация пакетов начинается с 1, как в Wireshark.

quit

Завершает работу bpf_dbg.

Компилятор JIT

Ядро Linux включает компилятор BPF JIT для платформ x86_64, SPARC, PowerPC, ARM, ARM64, MIPS, RISC-V, s390, который включается параметром конфигурации CONFIG_BPF_JIT. Компилятор JIT автоматически вызывается для каждого подключённого фильтра из пользовательского пространства или для внутренних пользователей, если это было разрешено командой

  echo 1 > /proc/sys/net/core/bpf_jit_enable

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

  echo 2 > /proc/sys/net/core/bpf_jit_enable

Ниже приведён пример вывода с помощью dmesg.

    [ 3389.935842] flen=6 proglen=70 pass=3 image=ffffffffa0069c8f
    [ 3389.935847] JIT code: 00000000: 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 68
    [ 3389.935849] JIT code: 00000010: 44 2b 4f 6c 4c 8b 87 d8 00 00 00 be 0c 00 00 00
    [ 3389.935850] JIT code: 00000020: e8 1d 94 ff e0 3d 00 08 00 00 75 16 be 17 00 00
    [ 3389.935851] JIT code: 00000030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 00 00
    [ 3389.935852] JIT code: 00000040: eb 02 31 c0 c9 c3

При включённой опции CONFIG_BPF_JIT_ALWAYS_ON для bpf_jit_enable устанавливается значение 1 и попытка поменять это значение приведёт к отказу. Это происходит и при установке bpf_jit_enable = 2, поскольку не рекомендуется выводить финальный дамп JIT в журнал ядра. Взамен рекомендуется выполнять самоанализ с помощью bpftool (из каталога tools/bpf/bpftool/).

В каталоге исходных кодов ядра tools/bpf/ имеется инструмент bpf_jit_disasm2 для вывода дизассемблированных дампов из журнала ядра.

	# ./bpf_jit_disasm
	70 bytes emitted from JIT compiler (pass:3, flen:6)
	ffffffffa0069c8f + <x>:
	0:	push   %rbp
	1:	mov    %rsp,%rbp
	4:	sub    $0x60,%rsp
	8:	mov    %rbx,-0x8(%rbp)
	c:	mov    0x68(%rdi),%r9d
	10:	sub    0x6c(%rdi),%r9d
	14:	mov    0xd8(%rdi),%r8
	1b:	mov    $0xc,%esi
	20:	callq  0xffffffffe0ff9442
	25:	cmp    $0x800,%eax
	2a:	jne    0x0000000000000042
	2c:	mov    $0x17,%esi
	31:	callq  0xffffffffe0ff945e
	36:	cmp    $0x1,%eax
	39:	jne    0x0000000000000042
	3b:	mov    $0xffff,%eax
	40:	jmp    0x0000000000000044
	42:	xor    %eax,%eax
	44:	leaveq
	45:	retq

Опция -o задаёт «аннотирование» кодов ассемблерных команд, которое может быть полезно для разработчиков JIT.

	# ./bpf_jit_disasm -o
	70 bytes emitted from JIT compiler (pass:3, flen:6)
	ffffffffa0069c8f + <x>:
	0:	push   %rbp
		55
	1:	mov    %rsp,%rbp
		48 89 e5
	4:	sub    $0x60,%rsp
		48 83 ec 60
	8:	mov    %rbx,-0x8(%rbp)
		48 89 5d f8
	c:	mov    0x68(%rdi),%r9d
		44 8b 4f 68
	10:	sub    0x6c(%rdi),%r9d
		44 2b 4f 6c
	14:	mov    0xd8(%rdi),%r8
		4c 8b 87 d8 00 00 00
	1b:	mov    $0xc,%esi
		be 0c 00 00 00
	20:	callq  0xffffffffe0ff9442
		e8 1d 94 ff e0
	25:	cmp    $0x800,%eax
		3d 00 08 00 00
	2a:	jne    0x0000000000000042
		75 16
	2c:	mov    $0x17,%esi
		be 17 00 00 00
	31:	callq  0xffffffffe0ff945e
		e8 28 94 ff e0
	36:	cmp    $0x1,%eax
		83 f8 01
	39:	jne    0x0000000000000042
		75 07
	3b:	mov    $0xffff,%eax
		b8 ff ff 00 00
	40:	jmp    0x0000000000000044
		eb 02
	42:	xor    %eax,%eax
		31 c0
	44:	leaveq
		c9
	45:	retq
		c3

Для разработчиков BPF JIT инструменты bpf_jit_disasm, bpf_asm и bpf_dbg обеспечивают средства разработки и тестирования компиляторов JIT в ядре.

Компоненты BPF в ядре

Внутри интерпретатора в ядре применяется иной формат набора инструкций с принципами, аналогичными базовым принципам BPF, описанным выше. Однако формат набора инструкций смоделирован ближе к базовой архитектуре, чтобы имитировать естественный набор инструкций для повышения производительности (см. ниже). Эту новую архитектуру ISA3 называют eBPF или internal BPF. eBPF является сокращением от [e]xtended BPF, что отличается от расширений BPF. eBPF представляет собой ISA, тогда как расширения BPF обозначают «классические» фильтры BPF с дополнением инструкций BPF_LD | BPF_{B,H,W} | BPF_ABS.

Набор инструкций рассчитан на компиляцию JIT с взаимно-однозначным отображением, что также может позволить использовать компиляторы GCC/LLVM для генерации оптимизированного кода eBPF с помощью eBPF backend, работающих почти так же быстро, как естественный код.

Новый набор инструкций исходно создавался для написания программ в стиле языка C с ограничениями и компиляции в eBPF с помощью дополнительного бэкэнда GCC/LLVM, чтобы можно было в нужный момент (just-in-time) выполнить отображение на современные 64-битовые CPU с минимальными потерями производительности в два этапа (C -> eBPF -> естественный код).

В настоящее время новый формат применяется для запуска пользовательских программ BPF, включая seccomp BPF, классические фильтры сокетов, классификаторы трафика cls_bpf, классификаторы групповых драйверов (team driver) для режима распределения нагрузки, расширений netfilter xt_bpf, диссекторов и классификаторов PTP и т. п. Все они преобразуются ядром в представление нового набора инструкций и выполняются интерпретатором eBPF. Для обработчиков в ядре это выполняется автоматически с помощью вызовов bpf_prog_create() для установки фильтров и bpf_prog_destroy() для их удаления. Функция bpf_prog_run(filter, ctx) автоматически вызывает интерпретатор eBPF или скомпилированный JIT код для работы фильтра. Параметр filter задаёт указатель на структуру bpf_prog, полученный от bpf_prog_create(), а ctx – текущий контекст (например, указатель на skb). Все ограничения для bpf_check_classic() применяются до преобразования к новой схеме.

В настоящее время классический формат BPF применяется для компиляции JIT на большинстве 32-битовых архитектур, а для x86-64, aarch64, s390x, powerpc64, sparc64, arm32, riscv64, riscv32 выполняется компиляция JIT из набора инструкций eBPF.

Основные изменения внутреннего формата перечислены ниже.

  • Число регистров увеличено с 2 до 10.

    В старом формате применялось 2 регистра (A и X), а также скрытый указатель на кадр. Новая схема имеет 10 внутренних регистров и доступный лишь для чтения указатель на кадр. Поскольку в 64-битовых CPU аргументы передаются функциям через регистры, число аргументов, передаваемых из программы eBPF во внутреннюю функцию ядра, ограничено пятью (5) и 1 регистр служит для возвращаемого функцией значения. Процессоры x86_64 передают первые 6 аргументов в регистрах, а aarch64, sparcv9, mips64 имеют 7 или 8 регистров для аргументов. В x86_64 имеется 6 сохраняемых вызываемой функцией регистров, а aarch64, sparcv9, mips64 – не менее 11.

    Соглашения для вызовов eBPF указаны ниже.

    • R0 – значение, возвращаемое внутренней функцией ядра, и код завершения для программы eBPF.

    • R1 – R5 – аргументы, передаваемые из программы eBPF внутренней функции ядра.

    • R6 – R9 – сохраняемые вызываемой функцией регистры.

    • R10 – доступный лишь для чтения указатель на стек доступа.

    Таким образом, для всех регистров eBPF обеспечивается взаимно-однозначное отображение на аппаратные (HW) регистры x86_64, aarch64 и т. п., а соглашения о вызовах eBPF напрямую отображаются на ABI4, используемые ядром 64-битовых платформ.

    На 32-битовых платформах JIT может отображать программы, использующие лишь 32-разрядную арифметику, и может поддерживать интерпретацию более сложных программ.

    R0 – R5 – это временные (scratch) регистры и программ eBPF должна при необходимости заполнять их при вызовах. Отметим, что существует лишь одна программа eBPF (eBPF main) и она не может вызывать другие функции eBPF, однако может обращаться ко встроенным функциям ядра.

  • Регистры расширены с 32 битов до 64.

    Семантика исходных 32-битовых операций ALU сохранена за счёт применения 32-битовых субрегистров. Все регистры eBPF являются 64-битовыми и младшие 32 бита служат субрегистром, а старшие заполняются нулями при записи в них. Это напрямую работает в архитектуре x86_64 и arm64, но для других JIT более сложно.

    На 32-битовых платформах 64-битовые внутренние программы BPF выполняются через интерпретатор. Их компиляторы JIT могут конвертировать программы BPF, использующие лишь 32-битовые субрегистры к естественному набору инструкций, а остальная часть интерпретируется.

    Операции являются 64-битовыми, поскольку на 64-битовых платформах указатели также имеют размер 64 бита и нужно передавать 64-битовые значения в функции ядра и из них, в ином случае 32-битовые регистры eBPF потребовали бы определений ABI для регистровых пар, что не позволило бы напрямую сопоставлять регистры eBPF с аппаратными регистрами и компилятору JIT потребовались бы операции объединения, расщепления и перемещения для каждого регистра при передаче в функцию или из неё, что было бы сложно, подвержено ошибкам и медленно. Другой причиной является применение 64-битовых атомарных счётчиков.

  • Условные цели jt/jf заменены на jt/fall-through.

    Конструкции вида «if (cond) jump_true; else jump_false;» в исходном решении заменены на конструкции вида «if (cond) jump_true; /* else fall-through */».

  • Введены bpf_call insn и соглашение о передаче регистров для вызовов с нулевыми издержками при передаче в другие функции ядра и из них.

    Перед вызовом встроенной функции ядра внутренней программе BPF нужно поместить аргументы функции в регистры R1 – R5 для выполнения соглашения о вызовах, после чего интерпретатор возьмёт значения из регистров и передаст их внутренней функции ядра. Если регистры R1 – R5 отображены на регистры CPU, используемые архитектурой для передачи аргументов, компилятору JIT не нужно выполнять дополнительные операции. Аргументы функции будут в нужных регистрах и инструкция BPF_CALL будет компилироваться JIT в одну аппаратную инструкцию вызова (call). Такое соглашение о вызовах было выбрано для охвата распространённых случаев без снижения производительности.

    После вызова встроенной функции ядра регистры R1 – R5 сбрасываются в нечитаемое состояние, а R0 содержит код возврата функции. Поскольку регистры R6 – R9 сохраняет вызываемая функция, они не меняются в результате вызова.

В качестве примера рассмотрим 3 приведённых ниже функций C.

    u64 f1() { return (*_f2)(1); }
    u64 f2(u64 a) { return f3(a + 1, a); }
    u64 f3(u64 a, u64 b) { return a - b; }

Компилятор GCC может преобразовать f1, f3 в команды x86_64

f1:

	movl $1, %edi
	movq _f2(%rip), %rax
	jmp  *%rax

f3:

	movq %rdi, %rax
	subq %rsi, %rax
	ret

Функция f2 в eBPF может иметь вид

f2:

	bpf_mov R2, R1
	bpf_add R1, 1
	bpf_call f3
	bpf_exit

Если f2 компилируется JIT и указатель сохраняется в _f2, вызовы и возврат f1 -> f2 -> f3 произойдут «без стыков» (seamless). Без JIT требуется интерпретатор __bpf_prog_run() для вызова f2.

По практическим причинам все программы eBPF имеют единственный аргумент ctx, который уже помещён в R1 (например, при запуске __bpf_prog_run()) и программа может вызывать функции ядра с числом аргументов до 5. Использование 6 и более аргументов в настоящее время не поддерживается, но это ограничение может быть снято в будущем.

На 64-битовых платформах все регистры взаимно-однозначно сопоставляются с аппаратными регистрами. Например, компилятор x86_64 JIT может отображать их как показано ниже.

    R0 - rax
    R1 - rdi
    R2 - rsi
    R3 - rdx
    R4 - rcx
    R5 - r8
    R6 - rbx
    R7 - r13
    R8 - r14
    R9 - r15
    R10 - rbp

Архитектура x86_64 ABI требует использовать rdi, rsi, rdx, rcx, r8, r9 для передачи аргументов, а rbx, r12 – r15 – для сохранения вызываемой функцией.

Приведённый ниже код внутренней псевдопрограммы BPF

    bpf_mov R6, R1 /* сохранение ctx */
    bpf_mov R2, 2
    bpf_mov R3, 3
    bpf_mov R4, 4
    bpf_mov R5, 5
    bpf_call foo
    bpf_mov R7, R0 /* сохранение значения, возвращаемого foo() */
    bpf_mov R1, R6 /* восстановление ctx для следующего вызова */
    bpf_mov R2, 6
    bpf_mov R3, 7
    bpf_mov R4, 8
    bpf_mov R5, 9
    bpf_call bar
    bpf_add R0, R7
    bpf_exit

после JIT для x86_64 может иметь вид

    push %rbp
    mov %rsp,%rbp
    sub $0x228,%rsp
    mov %rbx,-0x228(%rbp)
    mov %r13,-0x220(%rbp)
    mov %rdi,%rbx
    mov $0x2,%esi
    mov $0x3,%edx
    mov $0x4,%ecx
    mov $0x5,%r8d
    callq foo
    mov %rax,%r13
    mov %rbx,%rdi
    mov $0x6,%esi
    mov $0x7,%edx
    mov $0x8,%ecx
    mov $0x9,%r8d
    callq bar
    add %r13,%rax
    mov -0x228(%rbp),%rbx
    mov -0x220(%rbp),%r13
    leaveq
    retq

Код этого примера эквивалентен фрагменту C, показанному ниже.

    u64 bpf_filter(u64 ctx)
    {
	return foo(ctx, 2, 3, 4, 5) + bar(ctx, 6, 7, 8, 9);
    }

Встроенные функции ядра foo() и bar() с прототипом u64 (*)(u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5); будут получать аргументы в соответствующих регистрах и помещают возвращаемые значения в %rax (регистр R0 в eBPF). Пролог и эпилог функций создаются JIT и являются неявными в интерпретаторе. Регистры R0-R5 являются временными (scratch). Поэтому программа eBPF должна сохранять их при вызовах в соответствии с соглашением о вызовах. Например, приведённая ниже программа является некорректной.

    bpf_mov R1, 1
    bpf_call foo
    bpf_mov R0, R1
    bpf_exit

После вызова регистры R1-R5 содержат «хлам» и не могут быть прочитаны. Для проверки внутренних программ BPF служит встроенный в ядро блок проверки eBPF (verifier).

В новом решении eBPF поддерживает не более 4096 insn, это означает, что любая программа будет завершаться быстро и вызовет лишь фиксированное число функций ядра. Исходный формат BPF и новый формат используют команды с 2 операндами, что помогает выполнить взаимно-однозначное сопоставление между eBPF insn и x86 insn при компиляции JIT.

Указатель входного контекста для вызова функции интерпретатора является базовым и его содержимое определяется конкретным вариантом применения. Для seccomp регистр R1 указывает на seccomp_data, для преобразованных фильтров BPF – на skb.

Программа с внутренней трансляцией состоит из указанных ниже элементов

  op:16, jt:8, jf:8, k:32    ==>    op:8, dst_reg:4, src_reg:4, off:16, imm:32

На данный момент реализовано 87 внутренних инструкций BPF. 8-битовый код операции op позволяет определять новые команды. Некоторые инструкции могут использовать 16-, 24- и 32-битовое кодирование. Для совместимости с имеющимися инструкциями новые инструкции должны иметь размер, кратный 8 битам.

Внутренний BPF представляет собой набор инструкций общего назначения RISC. Не все регистры и инструкции применяются при трансляции из исходного BPF в новый формат. Например, фильтры сокетов не используют инструкцию exclusive add, а фильтры трассировки могут поддерживать счётчики событий. Регистр R9 не используется фильтрами сокетов, но более сложным фильтрам может не хватать регистров и они должны будут использовать стек.

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

Как и исходный BPF, новый формат работает в контролируемой среде, является детерминированным и ядро может легко доказать это. Безопасность программы можно определить за 2 шага (Проверка eBPF). Сначала выполняется поиск в глубину для исключения циклов и других проверок CFG, а второй шаг начинается с первого insn и проходит по всем возможным путям. Это имитирует выполнение всех insn с наблюдением смены состояний регистров и стека.

Представление операций eBPF

В eBPF используется большинство классических кодов операций для упрощения преобразования BPF в eBPF. Для переходов и арифметических операций 8-битовое поле code поделено на три части, как показано на рисунке.

  +----------------+--------+--------------------+
  |   4 бита       | 1 бит  |   3 бита           |
  |  код операции  |источник| класс инструкции   |
  +----------------+--------+--------------------+
  (MSB)                                      (LSB)

Три младших (LSB) бита задают класс инструкции, как показано в таблице.

Классы традиционного BPF

Классы eBPF

BPF_LD

0x00

BPF_LD

0x00

BPF_LDX

0x01

BPF_LDX

0x01

BPF_ST

0x02

BPF_ST

0x02

BPF_STX

0x03

BPF_STX

0x03

BPF_ALU

0x04

BPF_ALU

0x04

BPF_JMP

0x05

BPF_JMP

0x05

BPF_RET

0x06

BPF_JMP32

0x06

BPF_MISC

0x07

BPF_ALU64

0x07

Для классов BPF_ALU и BPF_JMP четвёртый бит представляет источник – BPF_K = 0x00 или BPF_X = 0x08.

  • В классическом BPF это означает:

	BPF_SRC(code) == BPF_X - операндом-источником служит регистр X;
	BPF_SRC(code) == BPF_K - операндом-источником является следующее 32-битовое значение.
  • В eBPF это означает:

	BPF_SRC(code) == BPF_X - операндом-источником служит регистр src_reg;
	BPF_SRC(code) == BPF_K - операндом-источником является следующее 32-битовое значение.

4 старших (MSB) бита задают код операции.

Для классов BPF_ALU и BPF_ALU64 (в eBPF) коды BPF_OP(code) приведены ниже.

  BPF_ADD   0x00
  BPF_SUB   0x10
  BPF_MUL   0x20
  BPF_DIV   0x30
  BPF_OR    0x40
  BPF_AND   0x50
  BPF_LSH   0x60
  BPF_RSH   0x70
  BPF_NEG   0x80
  BPF_MOD   0x90
  BPF_XOR   0xa0
  BPF_MOV   0xb0  /* только eBPF - перенос из регистра в регистр */
  BPF_ARSH  0xc0  /* только eBPF - добавление знака со сдвигом вправо */
  BPF_END   0xd0  /* только eBPF - смена порядка битов */

Для классов BPF_JMP и BPF_JMP32 (в eBPF) коды BPF_OP(code) приведены ниже.

  BPF_JA    0x00  /* только BPF_JMP */
  BPF_JEQ   0x10
  BPF_JGT   0x20
  BPF_JGE   0x30
  BPF_JSET  0x40
  BPF_JNE   0x50  /* только eBPF - jump != */
  BPF_JSGT  0x60  /* только eBPF - signed '>' */
  BPF_JSGE  0x70  /* только eBPF - signed '>=' */
  BPF_CALL  0x80  /* только eBPF BPF_JMP - вызов функции */
  BPF_EXIT  0x90  /* только eBPF BPF_JMP - возврат из функции */
  BPF_JLT   0xa0  /* только eBPF - unsigned '<' */
  BPF_JLE   0xb0  /* только eBPF - unsigned '<=' */
  BPF_JSLT  0xc0  /* только eBPF - signed '<' */
  BPF_JSLE  0xd0  /* только eBPF - signed '<=' */

Таким образом, BPF_ADD | BPF_X | BPF_ALU означает 32-битовое сложение в BPF и eBPF. В BPF имеется лишь 2 регистра и это означает A += X, а в eBPF это означает dst_reg = (u32) dst_reg + (u32) src_reg. Точно так же, BPF_XOR | BPF_K | BPF_ALU означает A ^= imm325 в BPF и src_reg = (u32) src_reg ^ (u32) imm32 в eBPF.

В BPF применяется класс BPF_MISC для представления переносов A = X и X = A, а в eBPF для этого служит код BPF_MOV | BPF_X | BPF_ALU. Поскольку в eBPF нет операций BPF_MISC, класс 7 применяется для операций BPF_ALU64, которые аналогичны BPF_ALU, но выполняются с 64-битовыми операндами. Таким образом, BPF_ADD | BPF_X | BPF_ALU64 указывает 64-битовое сложение, т. е. dst_reg = dst_reg + src_reg

В BPF класс BPF_RET представлен одной операцией ret. Классический код BPF_RET | BPF_K означает копирование значения imm32 в регистр возврата и завершение функции. eBPF моделируется в соответствии с CPU, поэтому код BPF_JMP | BPF_EXIT в eBPF означает лишь выход из функции. Программа eBPF должна сохранить возвращаемое значение в регистре R0 перед выполнением BPF_EXIT. Класс 6 в eBPF применяется как BPF_JMP32 для обозначения тех же операций, что и BPF_JMP, но со сравнением 32-битовых операндов.

Для команд загрузки и сохранения 8-битовое поле code поделено на три части, как показано на рисунке.

  +--------+--------+-------------------+
  | 3 бита | 2 бита |   3 бита          |
  | режим  | размер | класс инструкции  |
  +--------+--------+-------------------+
  (MSB)                             (LSB)

Возможные размеры указаны ниже.

  BPF_W   0x00    /* слово */
  BPF_H   0x08    /* полуслово */
  BPF_B   0x10    /* байт */
  BPF_DW  0x18    /* только eBPF - двойное слово */

Это поле определяет размер загружаемого или сохраняемого значения

 B  - 1 байт
 H  - 2 байта
 W  - 4 байта
 DW - 8 байт (только eBPF)

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

  BPF_IMM     0x00  /* перенос 32 битов в BPF и 64 в eBPF */
  BPF_ABS     0x20
  BPF_IND     0x40
  BPF_MEM     0x60
  BPF_LEN     0x80  /* только BPF, резерв в eBPF */
  BPF_MSH     0xa0  /* только BPF, резерв в eBPF */
  BPF_ATOMIC  0xc0  /* только eBPF - неделимые операции */

В eBPF инструкции (BPF_ABS | <size> | BPF_LD) и (BPF_IND | <size> | BPF_LD) служат для доступа к данным пакета. Это пришлось перенести из BPF для обеспечения высокой производительности фильтров сокетов при работе в интерпретаторе eBPF. Эти команды можно применять лишь в тех случаях, когда контекст интерпретатора является указателем на struct sk_buff и имеет 7 неявных операндов. Регистр R6 является неявным вводом, который должен содержать указатель на sk_buff, R0 является неявным выводом, содержащим извлечённые из пакета данные. Регистры R1 – R5 являются вспомогательными и недопустимо использовать их для сохранения данных при исполнении инструкции BPF_ABS | BPF_LD или BPF_IND | BPF_LD.

Эти инструкции имеют также неявное условие выхода из программы. При попытке программы eBPF обратиться к данным за пределами пакета интерпретатор будет прерывать исполнение программы. Поэтому компиляторы JIT должны сохранять это свойство. Поля src_reg и imm32 содержат явные входные данные для этих команд. Например, BPF_IND | BPF_W | BPF_LD означает

    R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32))

Содержимое регистров R1 – R5 не сохраняется.

В отличие от набора команд BPF в eBPF включены базовые операции загрузки и сохранения (load/store)

    BPF_MEM | <size> | BPF_STX:  *(size *) (dst_reg + off) = src_reg
    BPF_MEM | <size> | BPF_ST:   *(size *) (dst_reg + off) = imm32
    BPF_MEM | <size> | BPF_LDX:  dst_reg = *(size *) (src_reg + off)

Поле size в этих командах может принимать значение BPF_B, BPF_H, BPF_W или BPF_DW.

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

   .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W  | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg
   .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg

Поддерживаемые базовые неделимые операции указаны ниже.

    BPF_ADD
    BPF_AND
    BPF_OR
    BPF_XOR

Каждая из этих команд имеет семантику, эквивалентную BPF_ADD, т. е. адрес в памяти, указанный dst_reg + off, неделимо (atomically) изменяется с использованием src_reg в качестве другого операнда. Если флаг BPF_FETCH установлен напрямую, эти операции также переписывают src_reg значением, которое было в памяти до её изменения.

Более специализированная операция BPF_XCHG неделимо меняет src_reg значением, указанным адресом dst_reg + off. Операция BPF_CMPXCHG выполняет неделимое сравнение значения, указанного адресом dst_reg + off, со значением R0 и при совпадении заменяет его значением src_reg. Во всех случаях прежнее значение дополняется нулями и загружается обратно в R0.

Отметим, что 1- и 2-байтовые неделимые (atomic) операции не поддерживаются.

Clang может генерировать неделимые инструкции по умолчанию, если задана опция -mcpu=v3. При установке меньшей версии для -mcpu Clang может генерировать единственную неделимую инструкцию BPF_ADD без BPF_FETCH. Если нужно нужно включить неделимые операции при малых значениях версии -mcpu, можно использовать опции -Xclang -target-feature -Xclang +alu32.

BPF_XADD является устаревшим именем BPF_ATOMIC, указывающим операцию exclusive-add (монопольное сложение) при сброшенном (0) поле immediate.

В eBPF имеется инструкция BPF_LD | BPF_DW | BPF_IMM, состоящая из двух последовательных 8-байтовых блоков struct bpf_insn, интерпретируемых как загрузка непосредственного 64-битового значение в dst_reg. В BPF имеется похожая инструкция BPF_LD | BPF_W | BPF_IMM, загружающая непосредственное 32-битовое значение в регистр.

Проверка eBPF

Безопасность программы eBPF проверяется в два этапа.

Сначала выполняется проверка ациклического направленного графа (DAG6) для исключения петель и другие проверки CFG. В частности обнаруживаются программы с недоступными инструкциями (хотя проверка традиционного BPF разрешает их).

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

При старте программы регистр R1 содержит указатель на контекст и имеет тип PTR_TO_CTX. Если блок проверки insn, который делает R2=R1, регистр R2 также имеет тип тип PTR_TO_CTX и может использоваться в правой части выражений. Если R1=PTR_TO_CTX и insn имеет R2=R1+R1, то R2=SCALAR_VALUE, поскольку сложение двух действительных указателей даёт недействительный указатель (в защищённом (secure) режиме блок проверки будет отвергать любой тип арифметических операций с указателями, чтобы предотвратить утечку адресов из ядра к непривилегированным пользователям).

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

  bpf_mov R0 = R2
  bpf_exit

будет отвергнута, поскольку регистр R2 является нечитаемым при старте программы.

После вызова функции ядра, регистры R1 – R5 сбрасываются в нечитаемое состояние, а R0 имеет тип возврата из функции. Поскольку регистры R6-R9 сохраняет вызываемая функция, их состояние сохраняется в процессе вызова.

  bpf_mov R6 = 1
  bpf_call foo
  bpf_mov R0 = R6
  bpf_exit

Приведённая выше программа будет корректной. Если вместо R6 включить R1, программа будет отвергнута.

Команды загрузки и сохранения (load/store) разрешены только для регистров действительных типов, к которым относятся PTR_TO_CTX, PTR_TO_MAP, PTR_TO_STACK. Они ограничены и проверяются на предмет выравнивания. Например, программа

 bpf_mov R1 = 1
 bpf_mov R2 = 2
 bpf_xadd *(u32 *)(R1 + 3) += R2
 bpf_exit

будет отвергнута, поскольку R1 не имеет типа действительного указателя в момент выполнения bpf_xadd.

При старте R1 имеет тип PTR_TO_CTX (указатель на базовую struct bpf_context). Применяется обратный вызов (callback) для настройки блока проверки на разрешения программе eBPF доступа доступа лишь к некоторым полям структуры ctx с заданным размером и выравниванием. Например, insn.

  bpf_ld R0 = *(u32 *)(R6 + 8)

намерена загрузить слово с адресом R6 + 8 и записи его в R0. Если R6=PTR_TO_CTX, блок проверки через обратный вызов is_valid_access() узнает, что по данные смещению 8 с размером 4 байта, доступны для чтения. В иных случаях блок проверки будет отвергать программу. Если R6=PTR_TO_STACK, доступ следует выровнять с сохранением в границах стека [-MAX_BPF_STACK, 0). В этом примере смещение равно 8, поэтому он не пройдёт проверку (выход за границу).

Блок проверки будет разрешать программе eBPF читать данные из стека лишь после того, как они будут записаны.

Блок проверки в традиционном BPF выполняет подобные операции со слотами памяти M[0-15]. Например, программа

  bpf_ld R0 = *(u32 *)(R10 - 4)
  bpf_exit

не будет корректной. Хотя R10 является корректным регистром, доступным лишь для чтения (read-only), и имеет тип PTR_TO_STACK, R10 – 4 находится в границах стека, в указанное ими место не было записи.

Заполнение регистров также отслеживается, поскольку сохраняемых вызываемой функцией 4 регистров (R6 – R9) для некоторых программ может быть недостаточно.

Разрешённые вызовы функций настраиваются с помощью bpf_verifier_ops->get_func_proto(). Блок проверки eBPF будет контролировать соблюдение требований по выравниванию для регистров. После вызова в регистре R0 устанавливается тип возврата из функции.

Вызов функции является основным механизмом расширения функциональности программ eBPF. Фильтры сокетов могут разрешать программам вызывать некий набор функций, а фильтры трассировки – совсем иной набор.

Если функция доступна программе eBPF, необходимо рассмотреть её с точки зрения безопасности. Блок проверки гарантирует вызов функции с действительными (пригодными) аргументами.

Фильтры seccomp и фильтры сокетов имеют разные ограничения по безопасности в традиционном BPF. Для seccomp эта задача решается двухэтапной проверкой и блок проверки традиционного BPF использует логику проверки seccomp. В eBPF для всех случаев применяется один настраиваемый блок проверки. Дополнительную информацию можно получить из файла kernel/bpf/verifier.c в дереве исходных кодов ядра.

Отслеживание значений регистров

Для определения безопасности программы eBPF блок проверки должен отслеживать диапазоны возможных значений каждого регистра и каждого гнезда (slot) в стеке. Это зачастую выполняется с помощью struct bpf_reg_state (определена в include/linux/bpf_verifier.h), обеспечивающей однотипное отслеживание для скаляров и указателей. Каждое состояние регистра имеет тип, который может быть NOT_INIT (в регистр не было записи), SCALAR_VALUE (некое значение, не являющееся указателем) или указатель. Типы указателей приведены в таблице.

PTR_TO_CTX

Указатель на bpf_context.

CONST_PTR_TO_MAP

Указатель на struct bpf_map. Это постоянная (const), поскольку арифметические операции с такими указателями запрещены.

PTR_TO_MAP_VALUE

Указатель на значение, сохранённое в элементе отображения (map).

PTR_TO_MAP_VALUE_OR_NULL

Указатель на значение отображения или NULL. Доступ к отображению (Отображения eBPF) возвращает этот тип, который становится PTR_TO_MAP_VALUE после проверки != NULL. Арифметические операции с такими указателями запрещены.

PTR_TO_STACK

Указатель на кадр.

PTR_TO_PACKET

skb->data.

PTR_TO_PACKET_END

skb->data + headlen, арифметические операции запрещены.

PTR_TO_SOCKET

Указатель на struct bpf_sock_ops с неявным учётом ссылок.

PTR_TO_SOCKET_OR_NULL

Указатель на сокет или NULL. Поиск сокета возвращает этот тип, который становится PTR_TO_SOCKET после проверки != NULL. Ссылки на PTR_TO_SOCKET учитываются, поэтому программы должны освобождать ссылки с помощью функции освобождения сокета перед завершением программы. Арифметические операции с такими указателями запрещены.

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

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

  • Минимальное и максимальное значение в форме чисел без знака.

  • Минимальное и максимальное значение в форме чисел со знаком.

  • Сведения об отдельных битах в форме tnum – u64 mask и u64 value. Значение 1 в элементе mask представляет бит с неизвестным значением, 1 в value представляют биты со значением 1. Для битов со значением 0 указывается 0 в mask и value. Ни один из битов не может иметь значения 1 в маске и значении. Например, при чтении байта из памяти в регистр известно, что старшие 56 битов регистра имеют значение 0, а оставшиеся 8 неизвестны – это будет представляться в виде tnum (0x0; 0xff). Если затем для этого значения используется операция OR со значением 0x40, получается (0x40; 0xbf), а последующее сложение с 1 даёт (0x0; 0x1ff), из-за возможного переноса.

Помимо арифметических операций состояние регистра может меняться при ветвлении по условию. Например, при сравнении SCALAR_VALUE с условием > 8, ветвь true будет иметь значение (минимальное значение без знака) umin_value = 9, а ветвь false – umax_value = 8. Сравнение с учётом знака (BPF_JSGT или BPF_JSGE) будет обновлять минимальное и максимальное значение со знаком. Сведения о границах со знаком и без знака можно комбинировать, например, если сначала выполняется проверка value < 8, затем проверка s > 4, блок проверки может счесть, что value также > 4, а s< 8, поскольку границы не позволяют пересечь границу по знаку.

PTR_TO_PACKET с переменным смещением имеют идентификатор id, который является общим для всех указателей с тем же переменным смещением. Это важно для проверки диапазона в пакетах – после сложения переменной с регистром указателя для пакета (A) с последующим копированием в регистр B и прибавлением константы 4 к A оба регистра будут иметь общий идентификатор id, но A будет иметь фиксированное смещение +4. Если после этого для A выполняется проверка по границам и обнаруживается, что регистр меньше PTR_TO_PACKET_END, становится ясно, что регистр B имеет безопасный диапазон не менее 4 байтов. Диапазоны PTR_TO_PACKET более подробно описаны в параграфе Прямой доступ к пакетам.

Поле id применяется также в PTR_TO_MAP_VALUE_OR_NULL общем для всех указателей, возвращаемых при поиске в отображении (map). Это означает, что когда копия проверяется и обнаруживается, что она не пуста (non-NULL), все копии могут стать PTR_TO_MAP_VALUE. Как и проверка диапазонов, данные отслеживания служат для принудительного выравнивания доступа к указателям. Например, в большинстве систем указатель имеет размер 2 байта после выравнивания по 4-байтовой границе. Если программа добавляет 14 байтов для пропуска заголовка Ethernet, затем считывает поле IHL7 и добавляет (IHL * 4), полученный в результате указатель будет иметь переменное смещение, известное как 4n+2 для некоторого n, поэтому добавление 2 байтов (NET_IP_ALIGN) обеспечивает 4-байтовое выравнивание, поэтому доступ к слову по этому указателю не создаёт опасности.

Поле id применяется также в PTR_TO_SOCKET и PTR_TO_SOCKET_OR_NULL, общих для всех копий указателя, возвращаемых при поиске сокета. Это похоже на обработку PTR_TO_MAP_VALUE_OR_NULL->PTR_TO_MAP_VALUE, но включает также отслеживание ссылок для указателя. PTR_TO_SOCKET неявно представляет ссылку на соответствующую struct sock. Для предотвращения утечки ссылки необходимо выполнить проверку на NULL и в случае non-NULL передать действительную ссылку функции освобождения сокета.

Прямой доступ к пакетам

В программах cls_bpf и act_bpf блок проверки разрешает прямой доступ к данным пакета по указателям skb->data и skb->data_end. Например,

    1:  r4 = *(u32 *)(r1 +80)  /* загрузка skb->data_end */
    2:  r3 = *(u32 *)(r1 +76)  /* загрузка skb->data */
    3:  r5 = r3
    4:  r5 += 14
    5:  if r5 > r4 goto pc+16
    R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp
    6:  r0 = *(u16 *)(r3 +12) /* доступ к 12 и 13 байтам пакета */

Двухбайтовые загрузки (load) значений из пакета безопасны, поскольку программа выполняет проверку if (skb->data + 14 > skb->data_end) goto err в insn #5, в случае прохождения которой регистр R3 (указывает на skb->data) имеет по меньшей мере 14 доступных напрямую байтов. Блок проверки помечает его как R3=pkt(id=0,off=0,r=14). Здесь id=0 указывает отсутствие дополнительных переменных, прибавляемых к регистру, off=0 означает отсутствие прибавляемых констант, а r=14 указывает диапазон безопасного доступа, который говорит о доступности байтов [R3, R3 + 14).

Отметим, что регистр R5 указан как R5=pkt(id=0,off=14,r=14). Он тоже указывает данные пакета, но к регистру прибавляется константа 14 и он будет указывать skb->data + 14 и доступным диапазоном будет [R5, R5 + 14 – 14), содержащий 0 байтов.

Более сложный доступ к пакету может иметь вид

    R0=inv1 R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp
    6:  r0 = *(u8 *)(r3 +7) 	/* загрузка 7-байта из пакета */
    7:  r4 = *(u8 *)(r3 +12)
    8:  r4 *= 14
    9:  r3 = *(u32 *)(r1 +76)	/* загрузка skb->data */
    10:  r3 += r4
    11:  r2 = r1
    12:  r2 <<= 48
    13:  r2 >>= 48
    14:  r3 += r2
    15:  r2 = r3
    16:  r2 += 8
    17:  r1 = *(u32 *)(r1 +80)	/* загрузка skb->data_end */
    18:  if r2 > r1 goto pc+2
    R0=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=pkt_end R2=pkt(id=2,off=8,r=8) R3=pkt(id=2,off=0,r=8) R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)) R5=pkt(id=0,off=14,r=14) R10=fp
    19:  r1 = *(u8 *)(r3 +4)

Регистр R3 имеет состояние R3=pkt(id=2,off=0,r=8), id=2 означает, что видны две инструкции r3 += rX, поэтому R3 указывает некое смещение в пакете, а поскольку программа выполняет проверку if (r3 + 8 > r1) goto err в insn #18, безопасным диапазоном будет [R3, R3 + 8). Блок проверки разрешает доступ лишь операциям сложения и вычитания (add’/’sub) к регистрам пакета. Все прочие операции будут устанавливать регистр в состояние SCALAR_VALUE и он будет недоступен для прямого доступа к пакету.

Операция r3 += rX может приводить к переполнению, когда результат станет меньше исходного skb->data и блок проверки должен предотвращать это. Поэтому при наличии команды r3 += rX со значением rX более 16 битов любая последующее сравнение границы r3 с skb->data_end не будет давать сведений о диапазоне и попытки чтения по этому указателю приведёт к ошибке (invalid access to packet). Например, после r4 = *(u8 *)(r3 +12) (insn #7 выше ) регистр R4 будет иметь состояние R4=inv(id=0,umax_value=255,var_off=(0x0; 0xff)), которое означает, что 56 старших битов регистра гарантированно имеют значение 0, а о младших 8 битах ничего не известно. После r4 *= 14 состояние становится R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)), так как умножение 8-битового значения на константу 14 сохранит в 52 старших битах значение 0, а младший бит будет иметь значение 0, поскольку число 14 чётное. Аналогично r2 >>= 48 будет давать R2=inv(id=0,umax_value=65535,var_off=(0x0; 0xffff)), поскольку сдвиг не является расширением знака. Эта логика реализована в функции adjust_reg_min_max_vals(), вызывающей adjust_ptr_min_max_vals() для сложения указателя со скаляром (или наоборот) и adjust_scalar_min_max_vals() для операции над двумя скалярами.

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

  void *data = (void *)(long)skb->data;
  void *data_end = (void *)(long)skb->data_end;
  struct eth_hdr *eth = data;
  struct iphdr *iph = data + sizeof(*eth);
  struct udphdr *udp = data + sizeof(*eth) + sizeof(*iph);

  if (data + sizeof(*eth) + sizeof(*iph) + sizeof(*udp) > data_end)
	  return 0;
  if (eth->h_proto != htons(ETH_P_IP))
	  return 0;
  if (iph->protocol != IPPROTO_UDP || iph->ihl != 5)
	  return 0;
  if (udp->dest == 53 || udp->source == 9)
	  ...;

Это делает написание программы более простым по сравнению с LD_ABS insn и существенно ускоряет процесс.

Отображения eBPF

Отображение (map) является базовым хранилищем различных типов данных, совместно используемых ядром и пользовательским пространством. Доступ к map из пользовательского пространства выполняется с помощью системных вызовов BPF, указанных ниже.

  • Для создания отображения с заданным типом и атрибутами служит функция map_fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size), использующая attr->map_type, attr->key_size, attr->value_size, attr->max_entries и возвращающая файловый дескриптор локального процесса или отрицательный код ошибки.

  • Для поиска по ключу в заданном отображении применяется функция err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size), использующая attr->map_fd, attr->key, att->value и возвращающая 0 с сохранением найденного элемента или отрицательный код ошибки.

  • Для создания и обновления пар (ключ, значение) в данном отображении служит функция err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size), использующая attr->map_fd, attr->key, attr->value и возвращающая 0 или отрицательный код ошибки.

  • Для поиска и удаления элемента по ключу в данном отображении служит функция err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size), использующая attr->map_fd, attr->key.

  • Для удаления отображения служит close(fd).

При завершении процесса отображения удаляются автоматически. Программы пользовательского пространства применяют указанные вызовы для создания отображений и доступа к ним, а программы eBPF могут в то же время обновлять отображения. Отображения могут иметь тип hash, array, bloom filter, radix-tree и т. п. Отображение определяется:

  • типом;

  • максимальным числом элементов;

  • размером ключа в байтах;

  • размером значения в байтах.

Сокращение проверки

На практике блок проверки не проходит по всем возможным путям в программе. Для каждого анализируемого ветвления блок просматривает все состояния, в которых он был ранее при выполнении этой инструкции. Если какое-либо из них содержит текущее состояние как подмножество, ветвь «сокращается», т. е. факт предшествующего восприятия состояния подразумевает принятие текущего. Например, если в предыдущем состоянии R1 содержит указатель на пакет, а в текущем – указатель на пакет с таким же или большим размером и с не менее строгим выравниванием, R1 считается безопасным. Точно так же, если регистр R2 имел раньше состояние NOT_INIT, он не мог использоваться из этой точки, поэтому любое значение в R2 (включая NOT_INIT) безопасно. Реализация этого обеспечивается функцией regsafe(). Сокращение учитывает не только регистры, но и стек (и все регистры, которые он может включать). Все они должны быть безопасными для сокращения ветви. Это реализовано в функции states_equal().

Сообщения при проверке eBPF

Ниже приведено несколько примеров недействительных программ eBPF и сообщений блока проверки об ошибках, записываемых в журнал.

Программа с недоступными инструкциями

  static struct bpf_insn prog[] = {
  BPF_EXIT_INSN(),
  BPF_EXIT_INSN(),
  };

Ошибка

  unreachable insn 1

Программа, читающая неинициализированный регистр

  BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
  BPF_EXIT_INSN(),

Ошибка

  0: (bf) r0 = r2
  R2 !read_ok

Программа, не инициализирующая регистр R0 перед выходом

  BPF_MOV64_REG(BPF_REG_2, BPF_REG_1),
  BPF_EXIT_INSN(),

Ошибка

  0: (bf) r2 = r1
  1: (95) exit
  R0 !read_ok

Программа с доступом за границу стека

    BPF_ST_MEM(BPF_DW, BPF_REG_10, 8, 0),
    BPF_EXIT_INSN(),

Ошибка

    0: (7a) *(u64 *)(r10 +8) = 0
    invalid stack off=8 size=8

Программа, не инициализирующая стек до передачи его адреса функции

  BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
  BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
  BPF_LD_MAP_FD(BPF_REG_1, 0),
  BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
  BPF_EXIT_INSN(),

Ошибка

  0: (bf) r2 = r10
  1: (07) r2 += -8
  2: (b7) r1 = 0x0
  3: (85) call 1

Недействительное непрямое чтение из стека по смещению -8+0 с размером 8.

Программа, использующая недействительный дескриптор map_fd=0 при вызове функции map_lookup_elem()

  BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
  BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
  BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
  BPF_LD_MAP_FD(BPF_REG_1, 0),
  BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
  BPF_EXIT_INSN(),

Ошибка

  0: (7a) *(u64 *)(r10 -8) = 0
  1: (bf) r2 = r10
  2: (07) r2 += -8
  3: (b7) r1 = 0x0
  4: (85) call 1

fd 0 не указывает действительное отображение bpf_map.

Программа, не проверяющая возвращаемое map_lookup_elem() значение перед доступом к отображению

  BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
  BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
  BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
  BPF_LD_MAP_FD(BPF_REG_1, 0),
  BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
  BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 0),
  BPF_EXIT_INSN(),

Ошибка

  0: (7a) *(u64 *)(r10 -8) = 0
  1: (bf) r2 = r10
  2: (07) r2 += -8
  3: (b7) r1 = 0x0
  4: (85) call 1
  5: (7a) *(u64 *)(r0 +0) = 0

R0 указывает недействительный доступ к памяти map_value_or_null.

Программа с корректной проверкой возврата из map_lookup_elem() значения NULL и доступом к памяти с некорректным аргументом

  BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
  BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
  BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
  BPF_LD_MAP_FD(BPF_REG_1, 0),
  BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
  BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1),
  BPF_ST_MEM(BPF_DW, BPF_REG_0, 4, 0),
  BPF_EXIT_INSN(),

Ошибка

  0: (7a) *(u64 *)(r10 -8) = 0
  1: (bf) r2 = r10
  2: (07) r2 += -8
  3: (b7) r1 = 1
  4: (85) call 1
  5: (15) if r0 == 0x0 goto pc+1
   R0=map_ptr R10=fp
  6: (7a) *(u64 *)(r0 +4) = 0

Несогласованный доступ по смещению 4 с размером 8.

Программа с корректной проверкой возврата из map_lookup_elem() значения NULL и доступом к памяти с корректным аргументом на одной стороне ветвления if, но без этого на другой стороне if

  BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
  BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
  BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
  BPF_LD_MAP_FD(BPF_REG_1, 0),
  BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
  BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2),
  BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 0),
  BPF_EXIT_INSN(),
  BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 1),
  BPF_EXIT_INSN(),

Ошибка

  0: (7a) *(u64 *)(r10 -8) = 0
  1: (bf) r2 = r10
  2: (07) r2 += -8
  3: (b7) r1 = 1
  4: (85) call 1
  5: (15) if r0 == 0x0 goto pc+2
   R0=map_ptr R10=fp
  6: (7a) *(u64 *)(r0 +0) = 0
  7: (95) exit
  from 5 to 8: R0=imm0 R10=fp
  8: (7a) *(u64 *)(r0 +0) = 1
  R0 invalid mem access 'imm'

Программа, выполняющая поиск сокета, затем устанавливающая указатель NULL без проверки

  BPF_MOV64_IMM(BPF_REG_2, 0),
  BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8),
  BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
  BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
  BPF_MOV64_IMM(BPF_REG_3, 4),
  BPF_MOV64_IMM(BPF_REG_4, 0),
  BPF_MOV64_IMM(BPF_REG_5, 0),
  BPF_EMIT_CALL(BPF_FUNC_sk_lookup_tcp),
  BPF_MOV64_IMM(BPF_REG_0, 0),
  BPF_EXIT_INSN(),

Ошибка

  0: (b7) r2 = 0
  1: (63) *(u32 *)(r10 -8) = r2
  2: (bf) r2 = r10
  3: (07) r2 += -8
  4: (b7) r3 = 4
  5: (b7) r4 = 0
  6: (b7) r5 = 0
  7: (85) call bpf_sk_lookup_tcp#65
  8: (b7) r0 = 0
  9: (95) exit

Не освобождённая ссылка id=1, alloc_insn=7.

Программа, выполняющая поиск сокета, но не проверяющая возвращаемое значение на «не NULL»

  BPF_MOV64_IMM(BPF_REG_2, 0),
  BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8),
  BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
  BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
  BPF_MOV64_IMM(BPF_REG_3, 4),
  BPF_MOV64_IMM(BPF_REG_4, 0),
  BPF_MOV64_IMM(BPF_REG_5, 0),
  BPF_EMIT_CALL(BPF_FUNC_sk_lookup_tcp),
  BPF_EXIT_INSN(),

Ошибка

  0: (b7) r2 = 0
  1: (63) *(u32 *)(r10 -8) = r2
  2: (bf) r2 = r10
  3: (07) r2 += -8
  4: (b7) r3 = 4
  5: (b7) r4 = 0
  6: (b7) r5 = 0
  7: (85) call bpf_sk_lookup_tcp#65
  8: (95) exit

Не освобождённая ссылка id=1, alloc_insn=7.

Тестирование

Наряду с инструментами BPF ядро включает тестовый модуль с различными вариантами проверки для традиционного и внутреннего BPF, которые можно выполнить с интерпретатором BPF и компилятором JIT. Модуль размещается в файле lib/test_bpf.c и включается через Kconfig

  CONFIG_TEST_BPF=m

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

Пакет trinity

Пакет trinity для тестирования системных вызовов Linux имеет встроенную поддержку BPF и SECCOMP-BPF.

Авторы

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

Литература

[1] Documentation/userspace-api/seccomp_filter.rst (исходный код ядра).

[2] Steven McCanne, Van Jacobson. 1993. The BSD packet filter: a new architecture for user-level packet capture. In Proceedings of the USENIX Winter 1993 Conference Proceedings on USENIX Winter 1993 Conference Proceedings (USENIX’93). USENIX Association, Berkeley, CA, USA, 2-2. http://www.tcpdump.org/papers/bpf-usenix93.pdf.

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

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

nmalykh@protokols.ru

1Just-in-Time – компиляция в нужный момент.

2В новых версиях ядра он называется jit_disasm.

3instruction-set architecture.

4Application binary interface – двоичный интерфейс с приложениями.

5Следующие 32 бита.

6Directed acyclic graph.

7IP header length – размер заголовка IP.

Рубрика: Linux, Сетевое программирование | Оставить комментарий

RFC 9155 Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2

image_print
Internet Engineering Task Force (IETF)                     L. Velvindron
Request for Comments: 9155                                 cyberstorm.mu
Updates: 5246                                                K. Moriarty
Category: Standards Track                                            CIS
ISSN: 2070-1721                                               A. Ghedini
                                                         Cloudflare Inc.
                                                           December 2021

Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2

Отмена хэш-подписей MD5 и SHA-1 в TLS 1.2 и DTLS 1.2

PDF

Аннотация

Алгоритмы MD5 и SHA-1 становятся все более уязвимыми для атак и этот документ отменяет их использование в цифровых подписях TLS 1.2 и DTLS 1.2. Однако документ не отменяет применение SHA-1 в хэшированных кодах аутентификации сообщений (Hashed Message Authentication Code или HMAC) для защиты записей. Данный документ обновляет RFC 5246.

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

Документ относится к категории Internet Standards Track.

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

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

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

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

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

Оглавление

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

1. Введение

Использование MD5 и SHA-1 для хэширования подписей в (D)TLS 1.2 задано в [RFC5246]. За прошедшее время стало ясно, что алгоритмы MD5 и SHA-1 небезопасны и подвержены атакам с конфликтами (collision attack) [Wang]. В 2011 г. в [RFC6151] были подробно рассмотрены вопросы безопасности, включая collision-атаки на MD5. В NIST официально отказались от использования SHA-1 в 2011 г. [NISTSP800-131A-R2] и запретили использование этого алгоритма для цифровых подписей в конце 2013 г., основываясь на описании атак в [Wang] и возможности подбора (brute-force attack). В 2016 г. исследователи из INRIA3 обнаружили новый класс атак на основе конфликтов «расшифровки» (transcript) для протокола TLS (и других) за счёт алгоритма эффективного поиска конфликтов в базовых хэш-конструкциях [Transcript-Collision]. В 2017 г. исследователи из Google и CWI (Centrum Wiskunde & Informatica, Amsterdam) [SHA-1-Collision] доказали практическую осуществимость collision-атак на SHA-1. Этот документ обновляет [RFC5246], указывая недопустимость использования MD5 и SHA-1 в цифровых подписях. Однако документ не отменяет использование SHA-1 с HMAC для защиты записей. Отметим, что CABF (CA/Browser Forum) также отменил SHA-1 в подписях сертификатов [CABF].

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

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

2. Алгоритмы подписи

Клиенты должны включать расширение signature_algorithms и недопустимо включать в него MD5 или SHA-1.

3. Запрос сертификата

Серверам не следует включать MD5 и SHA-1 в сообщения CertificateRequest.

4. Обмен ключами с сервером

Серверам недопустимо включать MD5 и SHA-1 в сообщения ServerKeyExchange. Если клиент получает сообщение ServerKeyExchange, указывающее MD5 или SHA-1, он должен разорвать соединение с сигналом illegal_parameter.

5. Проверка сертификата

Клиентам недопустимо включать MD5 или SHA-1 в сообщения CertificateVerify. Если сервер получает CertificateVerify с или SHA-1, он должен разорвать соединение с сигналом illegal_parameter.

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

Агентство IANA обновило реестр TLS SignatureScheme, заменив рекомендуемый статус схем подписи на основе SHA-1 на N (не рекомендуется), как указано в [RFC8447]. Обновлённые записи указаны в таблице 1.

Таблица 1.

Значение

Описание

Рекомендуется

Ссылки

0x0201

rsa_pkcs1_sha1

N

[RFC8446] [RFC9155]

0x0203

ecdsa_sha1

N

[RFC8446] [RFC9155]

Агентство IANA также обновило ссылки в реестрах TLS SignatureAlgorithm и TLS HashAlgorithm, указав этот документ в дополнение к RFC 5246 и RFC 8447.

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

Современные реализации (D)TLS 1.2 с откатом к SHA-1 создают проблемы. Этот документ обновляет спецификацию TLS 1.2 [RFC5246] для отмены поддержки алгоритмов цифровой подписи MD5 и SHA-1. Однако документ не отменяет применение SHA-1 в HMAC для защиты записей.

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

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

[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

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

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

[RFC8447] Salowey, J. and S. Turner, “IANA Registry Updates for TLS and DTLS”, RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.

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

[CABF] CA/Browser Forum, “Ballot 118 — SHA-1 Sunset (passed)”, October 2014, <https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/>.

[NISTSP800-131A-R2] Barker, E. and A. Roginsky, “Transitioning the Use of Cryptographic Algorithms and Key Lengths”, NIST Special Publication 800-131A, Revision 2, DOI 10.6028/NIST.SP.800-131Ar2, March 2019, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf>.

[RFC6151] Turner, S. and L. Chen, “Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms”, RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.

[SHA-1-Collision] Stevens, M., Bursztein, E., Karpman, P., Albertini, A., and Y. Markov, “The First Collision for Full SHA-1”, 2017, <https://eprint.iacr.org/2017/190>.

[Transcript-Collision] Bhargavan, K. and G. Leurent, “Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH”, DOI 10.14722/ndss.2016.23418, February 2016, <https://hal.inria.fr/hal-01244855/document>.

[Wang] Wang, X., Yin, Y., and H. Yu, “Finding Collisions in the Full SHA-1”, DOI 10.1007/11535218_2, 2005, <https://www.iacr.org/archive/crypto2005/36210017/36210017.pdf>.

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

Авторы благодарны Hubert Kario за помощь при подготовке предварительной версии этого документа. Спасибо также Daniel Migault, Martin Thomson, Sean Turner, Christopher Wood, David Cooper за их отклики.

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

Loganaden Velvindron
cyberstorm.mu
Rose Hill
Mauritius
Phone: +230 59762817
Email: logan@cyberstorm.mu
 
Kathleen Moriarty
Center for Internet Security
East Greenbush, NY
United States of America
Email: Kathleen.Moriarty.ietf@gmail.com
 
Alessandro Ghedini
Cloudflare Inc.
Email: alessandro@cloudflare.com

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

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

nmalykh@protokols.ru

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

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

3National Institute for Research in Digital Science and Technology – Национальный институт исследований в сфере цифровых наук и технологий США.

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

RFC 9144 Comparison of Network Management Datastore Architecture (NMDA) Datastores

image_print
Internet Engineering Task Force (IETF)                          A. Clemm
Request for Comments: 9144                                         Y. Qu
Category: Standards Track                                      Futurewei
ISSN: 2070-1721                                              J. Tantsura
                                                               Microsoft
                                                              A. Bierman
                                                               YumaWorks
                                                           December 2021

Comparison of Network Management Datastore Architecture (NMDA) Datastores

Сравнение хранилищ данных управления сетью (NMDA)

PDF

Аннотация

Этот документ определяет операцию удалённого вызова процедуры (Remote Procedure Call или RPC) для сравнения архитектуры NMDA1.

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

Документ относится к категории Internet Standards Track.

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

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

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

Авторские права (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. Введение

При пересмотре архитектуры NMDA [RFC8342] добавлены новые хранилища данных, поддерживающие формат YANG [RFC7950] и предоставляющие различные «точки зрения» (viewpoint) для поддерживаемых сервером данных. Новые хранилища YANG включают раздел <intended>, содержащий проверенные данные конфигурации, которое клиентское приложение планирует ввести в действие, и раздел <operational>, содержащий данные рабочего состояния (такие как статистика), а также реально применяемые данные конфигурации.

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

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

Данные могут передаваться между хранилищами и возможно различие данных в разных хранилищах. Отчасти это ожидаемо, поскольку может возникать временной интервал между передачей конфигурации устройству с её отражением в хранилище <intended> и фактическим применением с отражением в <operational>. Однако в некоторых случаях элемент конфигурации, который должен быть применён, может не вступить в силу или на это потребуется длительное время. Это может быть обусловлено несоблюдением тех или иных условий, нераспространением отдельных частей конфигурации, сочтённых неактивными, несоблюдением зависимостей от ресурсов или ошибками реализации при задании условий.

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

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

В этом документе вводится модель данных YANG, определяющая RPC, предназначенные для использования с протоколами NETCONF [RFC6241] и RESTCONF [RFC8040]. Эти RPC позволяют клиенту запросить у сервера сравнение двух хранилищ NMDA и отчёт о различиях между ними.

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

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

3. Обзор модели данных

Основой решения является новая операция управления <compare>, сравнивающая содержимое дерева данных в двух хранилищах. Эта операция отыскивает различия в значениях или узлах данных обоих хранилищ и возвращает найденные расхождения. Вывод имеет формат, заданный в YANG Patch [RFC8072].

Модель данных YANG определяет операцию <compare> как новую процедуру RPC. Входные параметры операции указаны ниже.

source – источник

Указывает хранилище, служащее основой (эталоном) для сравнения, например, <intended>.

target – назначение

Указывает хранилище, сравниваемое с эталонным (source), например, <operational>.

filter-spec – спецификация фильтра

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

all – все

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

report-origin – источник отчёта

Указывает, что метаданные об источнике следует включать в вывод RPC. При отсутствии параметра метаданные источника в сравнении, включающем <operational>, по умолчанию опускаются. Отметим, что метаданные источника применимы лишь к хранилищу <operational> и не указываются в сравнении, не включающем <operational>, независимо от наличия этого параметра.

Операция представляет на выходе один параметр, описанный ниже.

differences – различия

Этот параметр содержит список различий, представляемых в соответствии с моделью данных YANG Patch [RFC8072]. Когда узел хранилища данных в эталонном источнике отсутствует в целевом хранилище, это может быть указано как delete или remove в файле различий (patch), поскольку сравнение здесь невозможно. Модель данных YANG Patch была дополнена для указания узлов эталонного хранилища (в дополнение к самому исправлению), которые нужно применить к источнику для создания целевого объекта. Когда целевым является хранилище <operational> и установлен входной параметр report-origin, метаданные источника включаются как часть исправления (patch). Это может помочь в объяснении причин различия в некоторых случаях, например, когда узел данных является частью <intended>, но источник того же узла в <operational> указан как system.

Модель данных определена в модуле YANG ietf-nmda-compare, структура которого показана ниже, в соответствии с обозначениями из [RFC8340].

   module: ietf-nmda-compare
     rpcs:
       +---x compare
          +---w input
          |  +---w source            identityref
          |  +---w target            identityref
          |  +---w all?              empty
          |  +---w report-origin?    empty
          |  +---w (filter-spec)?
          |     +--:(subtree-filter)
          |     |  +---w subtree-filter?
          |     +--:(xpath-filter)
          |        +---w xpath-filter?     yang:xpath1.0 {nc:xpath}?
          +--ro output
             +--ro (compare-response)?
                +--:(no-matches)
                |  +--ro no-matches?    empty
                +--:(differences)
                   +--ro differences
                      +--ro yang-patch
                         +--ro patch-id    string
                         +--ro comment?    string
                         +--ro edit* [edit-id]
                            +--ro edit-id         string
                            +--ro operation       enumeration
                            +--ro target          target-resource-offset
                            +--ro point?          target-resource-offset
                            +--ro where?          enumeration
                            +--ro value?
                            +--ro source-value?

Рисунок 1. Структура ietf-nmda-compare.

4. Модель данных YANG

Этот модуль YANG включает ссылки на [RFC6991], [RFC8342], [RFC8072], and [RFC6241].

   <CODE BEGINS> file "ietf-nmda-compare@2021-12-10.yang"
   module ietf-nmda-compare {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-compare";
     prefix cmp;

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-datastores {
       prefix ds;
       reference
         "RFC 8342: Network Management Datastore
          Architecture (NMDA)";
     }
     import ietf-yang-patch {
       prefix ypatch;
       reference
         "RFC 8072: YANG Patch Media Type";
     }
     import ietf-netconf {
       prefix nc;
       reference
         "RFC 6241: Network Configuration Protocol (NETCONF)";
     }

     organization
       "IETF NETMOD (Network Modeling) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/> 
        WG List:  <mailto:netmod@ietf.org> 

        Author: Alexander Clemm
                <mailto:ludwig@clemm.org> 

        Author: Yingzhen Qu
                <mailto:yqu@futurewei.com> 

        Author: Jeff Tantsura
                <mailto:jefftant.ietf@gmail.com> 

        Author: Andy Bierman
                <mailto:andy@yumaworks.com>"; 
     description
       "Модель данных YANG определяет новую операцию <compare>, которая
        может применяться для сравнения хранилищ NMDA.

        Авторские права (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 9144, где правовые
        аспекты приведены более полно.";

     revision 2021-12-10 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9144: Comparison of Network Management Datastore
          Architecture (NMDA) Datastores";
     }

     /* RPC */
     rpc compare {
       description
         "Операция сравнения хранилищ данных NMDA.";
       input {
         leaf source {
           type identityref {
             base ds:datastore;
           }
           mandatory true;
           description
             "Хранилище-образец для сравнения.";
         }
         leaf target {
           type identityref {
             base ds:datastore;
           }
           mandatory true;
           description
             "Сравниваемое с образцом хранилище.";
         }
         leaf all {
           type empty;
           description
             "При наличии этого листа сравниваются все узлы данных
              независимо от их присутствия в 1 или обоих хранилищах.
              При отсутствии листа автоматически применяется 
              предопределённый фильтр для исключения узлов данных,
              имеющихся лишь в одном из хранилищ. В частности, если
              одно из хранилищ (source или target) содержит лишь данные
              данные конфигурации, а другим служит <operational>, узлы
              данных с config false исключаются из сравнения.";
         }
         leaf report-origin {
           type empty;
           description
             "При наличии этого листа метаданные источника включаются в
              вывод RPC. При отсутствии листа метаданные источника в
              сравнении с участием <operational> опускаются.";
         }
         choice filter-spec {
           description
             "Указывает сравниваемые части хранилища данных.";
           anydata subtree-filter {
             description
               "Указывает искомые части целевого хранилища данных.";
             reference
               "RFC 6241, Section 6.";
           }
           leaf xpath-filter {
             if-feature "nc:xpath";
             type yang:xpath1.0;
             description
               "Выражение XPath, указывающее искомые части целевого
                хранилища.";
             reference
               "RFC 6991: Common YANG Data Types";
           }
         }
       }
       output {
         choice compare-response {
           description
             "Результаты сравнения.";
           leaf no-matches {
             type empty;
             description
               "Указывает, что фильтру не соответствует ничего
                и сравнения не выполняется.";
           }
           container differences {
             description
               "Список различий в формате RFC 8072 с дополнением для
                включения исходных значений, когда это применимо. При
                отсутствии узла хранилища source в хранилище target
                это может быть указано как delete или remove, поскольку
                различий нет из-за отсутствия сравнения.";
             uses ypatch:yang-patch {
               augment "yang-patch/edit" {
                 description
                   "Указывает источник исправления (source) относительно
                    источника при сравнении в дополнение к значению
                    target, когда это применимо.";
                 anydata source-value {
                   when "../operation = 'delete'"
                      + "or ../operation = 'merge'"
                      + "or ../operation = 'move'"
                      + "or ../operation = 'replace'"
                      + "or ../operation = 'remove'";
                   description
                     "Значение anydata применяется лишь для операций 
                      delete, move, merge, replace, remove.";
                 }
                 reference
                   "RFC 8072: YANG Patch Media Type";
               }
             }
           }
         }
       }
     }
   }
   <CODE ENDS>

5. Пример

Ниже приведён пример сравнения в хранилищах <operational> и <intended> субдерева interfaces. Это субдерево содержит подмножество объектов, заданных в модели данных YANG для управления интерфейсами в [RFC8343]. Для понимания приведённого примера ниже приведён фрагмент модели данных, создающий экземпляр, служащий для сравнения.

   container interfaces {
     description
       "Параметры интерфейса.";
     list interface {
       key "name";
       leaf name {
         type string;
         description
           "Имя интерфейса.";
       }
       leaf description {
         type string;
         description
           "Текстовое описание интерфейса.";
       }
       leaf enabled {
         type boolean;
         default "true";
         description
           "Заданное конфигурацией желаемое состояние интерфейса.";
       }
     }
   }

Ниже показано содержимое хранилищ <intended> и <operational> в формате XML [W3C.REC-xml-20081126].

   <!--INTENDED-->
   <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
     <interface>
       <name>eth0</name>
       <enabled>false</enabled>
       <description>ip interface</description>
     </interface>
   </interfaces>

   <!--OPERATIONAL-->
   <interfaces
       xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
     <interface or:origin="or:learned">
       <name>eth0</name>
       <enabled>true</enabled>
     </interface>
   </interfaces>

Хранилище <operational> не включает экземпляр листа description, имеющийся в <intended>, а лист enabled имеет в хранилищах разное значение (true в <operational> и false в <intended>). Лист name в обоих хранилищах совпадает. Источником экземпляров листьев в <operational> указано изучение (learned), что может помочь в понимании причины различия.

RPC запрашивает сравнение <operational> (образец) с <intended> (цель сравнения).

   <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <compare xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
         xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
       <source>ds:operational</source>
       <target>ds:intended</target>
       <report-origin/>
       <xpath-filter
           xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">
         /if:interfaces
       </xpath-filter>
     </compare>
   </rpc>

Отклик RPC с найденными различиями представлен ниже.

   <rpc-reply
        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
        message-id="101">
     <differences
        xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
        xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
       <yang-patch>
         <patch-id>interface status</patch-id>4
         <comment>
           diff between operational (source) and intended (target)5
         </comment>
         <edit>
           <edit-id>1</edit-id>
           <operation>replace</operation>6
           <target>/ietf-interfaces:interface=eth0/enabled</target>
           <value>
             <if:enabled>false</if:enabled>
           </value>
           <source-value>
              <if:enabled or:origin="or:learned">true</if:enabled>
           </source-value>
         </edit>
         <edit>
           <edit-id>2</edit-id>
           <operation>create</operation>7
           <target>/ietf-interfaces:interface=eth0/description</target>
           <value>
             <if:description>ip interface</if:description>
           </value>
         </edit>
       </yang-patch>
     </differences>
   </rpc-reply>

Такой же запрос в RESTCONF (с использованием формата JSON [RFC7951]) показан ниже.

   POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data+json
   Accept: application/yang-data+json

   { "ietf-nmda-compare:input" : {
      "source" : "ietf-datastores:operational",
      "target" : "ietf-datastores:intended",
      "report-origin" : null,
      "xpath-filter" : "/ietf-interfaces:interfaces"
      }
   }

Запрос RESTCONF (в формате JSON) даст показанный ниже результат.

   HTTP/1.1 200 OK
   Date: Thu, 24 Jan 2019 20:56:30 GMT
   Server: example-server
   Content-Type: application/yang-data+json

   { "ietf-nmda-compare:output" : {
       "differences" : {
         "ietf-yang-patch:yang-patch" : {
           "patch-id" : "interface status",
           "comment" : "diff between intended (source) and operational",2
           "edit" : [
             {
               "edit-id" : "1",
               "operation" : "replace",8
               "target" : "/ietf-interfaces:interface=eth0/enabled",
               "value" : {
                  "ietf-interfaces:interface/enabled" : "false"
               },
               "source-value" : {
                  "ietf-interfaces:interface/enabled" : "true",
                  "@ietf-interfaces:interface/enabled" : {
                    "ietf-origin:origin" : "ietf-origin:learned"
                  }
                }
             },
             {
               "edit-id" : "2",
               "operation" : "create",9
               "target" : "/ietf-interfaces:interface=eth0/description",
               "value" : {
                 "ietf-interface:interface/description" : "ip interface"
               }
             }
           ]
         }
       }
     }
   }

6. Вопросы производительности

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

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

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

7.1. Обновление реестра IETF XML

Агентство IANA обновило URI в реестре IETF XML [RFC3688], как показано ниже.

   URI:  urn:ietf:params:xml:ns:yang:ietf-nmda-compare
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

7.2. Обновление реестра YANG Module Names

Агентство IANA зарегистрировало новый модуль YANG в реестре YANG Module Names [RFC6020].

   name:  ietf-nmda-compare
   namespace:  urn:ietf:params:xml:ns:yang:ietf-nmda-compare
   prefix:  cmp
   reference:  RFC 9144

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

Заданный в этом документе модуль YANG определяет схему для данных, которая предназначена для доступа по протоколу сетевого управления, такому как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижележащим уровнем для NETCONF является защищённый транспортный уровень с обязательной реализацией протокола Secure Shell (SSH) [RFC6242], а для RESTCONF – протокол HTTPS с обязательной реализацией защищённого транспорта TLS [RFC8446].

Модель доступа к конфигурации сети (Network Configuration Access Control Model или NACM) [RFC8341] обеспечивает возможность предоставлять доступ лишь отдельным пользователям NETCONF или RESTCONF к заданному подмножестве операций NETCONF или RESTCONF и содержимого. NACM определяет доступ к серверу в целом, а также правила доступа ко всем его хранилищам. Все субдеревья, к которым запрашивающему не предоставлен доступ, пропускаются и не учитываются в сравнении.

Определённая в этом модуле YANG операция RPC <compare> может быть чувствительной или уязвимой в некоторых сетевых средах, поэтому важно контролировать доступ к этой операции. Чувствительные и уязвимые аспекты операции RPC <compare> указаны ниже.

Сравнение хранилищ на предмет различий требует использования вычислительных ресурсов сервера. Злоумышленник может попытаться атаковать сервер, передавая ему запросы с большим объёмом сравнения. Реализации серверов могут защитить себя несколькими способами. Во-первых, можно реализовать модель NACM для корректной проверки полномочий при запросах. Во-вторых, можно ограничивать число запросов, принимаемых от клиента в интервале времени, отвергая запросы, которые реализация не способна разумно поддерживать.

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

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

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

[RFC7951] Lhotka, L., “JSON Encoding of Data Modeled with YANG”, RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

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

[RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, “YANG Patch Media Type”, RFC 8072, DOI 10.17487/RFC8072, February 2017, <https://www.rfc-editor.org/info/rfc8072>.

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

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

[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. Дополнительная литература

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

Приложение A. Возможные в будущем расширения

В будущем возможно расширение операции <compare> разными дополнительными функциями.

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

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

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

Спасибо Rob Wilton, Martin Bjorklund, Mahesh Jethanandani, Lou Berger, Kent Watsen, Phil Shafer, Ladislav Lhotka, Tim Carey, Reshad Rahman за их отклики и предложения.

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

Alexander Clemm
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: ludwig@clemm.org
 
Yingzhen Qu
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yqu@futurewei.com
 
Jeff Tantsura
Microsoft
Email: jefftant.ietf@gmail.com
 
Andy Bierman
YumaWorks
Email: andy@yumaworks.com

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

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

nmalykh@protokols.ru

1Network Management Datastore Architecture – архитектура хранилища данных управления сетью.

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

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

4Состояние интерфейса.

5Отличие рабочего состояния от предполагаемого (intended).

6Операция смены состояния интерфейса (disabled на enabled).

7Создание описания в хранилище <intended>.

8Смена состояния интерфейса.

9Создание описания интерфейса.

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

RFC 9138 Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

image_print
Internet Research Task Force (IRTF)                              J. Hong
Request for Comments: 9138                                        T. You
Category: Informational                                             ETRI
ISSN: 2070-1721                                                  L. Dong
                                                             C. Westphal
                                             Futurewei Technologies Inc.
                                                               B. Ohlman
                                                                Ericsson
                                                           November 2021

Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

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

PDF

Аннотация

В этом документе рассматриваются вопросы функциональности и проектирования служб распознавания имён (Name Resolution Service или NRS) в ориентированных на информацию сетях (Information-Centric Networking или ICN). Целью NRS в ICN является трансляция имени объекта в некую иную информацию, такую как местоположение (locator), другое имя и т. п. Документ является результатом исследовательской группы ICNRG1.

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

Этот документ не содержит спецификации стандарта Internet (Standards Track) и публикуется с информационными целями.

Документ является результатом работы IRTF2. IRTF публикует результаты связанных Internet исследований и разработок. Эти результаты могут не подходить для развёртывания. Данный документ представляет согласованное мнение исследовательской группы Information-Centric Networking в составе IRTF. Документы, одобренные для публикации IRSG не являются кандидатами в какие-либо стандарты Internet (см. раздел 2 в RFC 7841).

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

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

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. Введение

Сеть Internet в настоящее время основана на парадигме, ориентированной на хосты, где хосты указываются адресами IP, а взаимодействие происходит между парой хостов. Таким образом, информация в Internet сейчас идентифицируется именем хоста (или сервера), где она хранится. В отличие от ориентированных на хосты сетей основными объектами взаимодействия в ориентированной на информацию сети (ICN) являются объекты именованных данных (named data object или NDO), которые однозначно указываются независимыми от местоположения именами. Таким образом, сети ICN нацелены на эффективное распространение и извлечение объектов NDO в глобальном масштабе и эта технология была признана многообещающей архитектурой будущей сети Internet для преодоления современных ограничений Internet, в таких сферах, как расширяемость и мобильность [Ahlgren] [Xylomenos]. ICN также является кандидатом при выборе архитектуры «Internet вещей» (Internet of Things или IoT), поскольку IoT фокусируется на данных и информации [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2].

Поскольку именование данных, не зависящее от их текущего местоположения (хранилища) является основной концепцией ICN, отыскание NDO с использованием независимого от местоположения имени является одной из важнейших задач при проектировании ICN. Маршрутизацию ICN можно разделить на 3 этапа [RFC7927]:

  1. распознавание имени – сопоставление (и трансляция) имени содержимого с местоположением (locator) издателя содержимого или источника, способного предоставить содержимое;

  2. маршрутизация запроса содержимого к местоположению этого содержимого по локатору или имени;

  3. доставка содержимого запросившей его стороне.

Из отмеченных 3 этапов маршрутизации ICN в этом документе рассматривается этап 1 – распознавание имён, при котором имя содержимого транслируется в его местоположение (locator). Кроме того, докуме6нт охватывает возможные типы распознавания имён в ICN, такие как преобразование имени в другое имя, манифест или метаданные.

Этот документ сосредоточен на службе распознавания имён (NRS) как услуге или системе в ICN и представляет функциональность и аспекты проектирования NRS в ICN, а также даёт обзор подходов к NRS. Сопутствующий документ [NRSarch] рассматривает вопросы с точки зрения архитектуры ICN и системы маршрутизации при использовании NRS в ICN.

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

2. Служба распознавания имён в ICN

Служба распознавания имён (NRS) в ICN определяется как служба, обеспечивающая функцию распознавания имён для трансляции имени объекта в иные сведения, такие как местоположение, другое имя, метаданные, сведения о следующем интервале пересылки (next-hop) и т. п., которые применяются для пересылки запроса объекта. Иными словами, служба NRS может предоставляться инфраструктурой ICN, чтобы помочь потребителю получить нужные сведения (или именованный объект данных). Потребитель предоставляет NRS постоянное имя, а NRS возвращает имя или местоположение (locator), возможно в нескольких экземплярах, для получения текущего экземпляра запрошенного объекта.

Распознавание имён является важной частью маршрутизации ICN, хотя сам процесс распознавания может быть отделен от маршрутизации запросов содержимого или быть встроенным в маршрутизацию запросов содержимого как неявный процесс. Первый вариант в этом документе называется явным распознаванием (explicit name resolution), второй – маршрутизацией по именам (name-based routing).

2.1. Явное распознавание имён

NRS может использовать явное распознавание имён для возврата клиенту местоположения содержимого и базовая сеть будет использовать это местоположение в качестве идентификатора для маршрутизации запроса клиента к одному из издателей или копии содержимого. Есть несколько проектов ICN, использующих явное распознавание, например ориентированная на данные архитектура сети (Data-Oriented Network Architecture или DONA) [Koponen], PURSUIT [PURSUIT], сеть информации (Network of Information или NetInf) [SAIL], MobilityFirst [MF], IDNet [Jung] и др. Кроме того, явное распознавание имён также разрешено в плоскостях управления 5G [SA2-5GLAN].

2.2. Маршрутизация по именам

NRS может принимать подход с маршрутизацией по именам, где распознавание имен интегрировано с маршрутизацией запросов содержимого, как в сетях именованных данных и ориентированных на содержимое сетях (Named Data Networking / Content-Centric Networking или NDN/CCNx) [NDN] [CCNx].

Когда запрос содержимого задаёт и обратный путь, как в NDN/CCNx, механизм распознавания имён также выводит путь для маршрутизации данных. Это добавляет для службы распознавания имён требование распространять запрос в соответствии с последующей пересылкой данных. Запрос должен выбирать путь для данных на основе поиска копии нужного содержимого с учётом подобающей доставки данных.

2.3. Гибридный подход

В NRS может также применяться гибридный подход. Например, можно сначала попытаться использовать маршрутизацию на основе имён, а при неудаче на том или ином маршрутизаторе он может вернуться к явному распознаванию имён. Гибридный вариант NRS работает и обратным способом – сначала выполняется явное распознавание имён для поиска местоположения маршрутизаторов, а затем – маршрутизация клиентского запроса с использованием подхода для маршрутизации по имени.

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

2.4. Сравнение подходов к распознаванию имён

Ниже приведено сравнение нескольких аспектов явного распознавания имён и маршрутизации по именам.

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

  • Возможность распознавания. Если явное распознавание имён реализовано и развёрнуто с достаточной отказоустойчивостью, имеется хоть какая-то гарантия успешного распознавания любого имени содержимого в сети, зарегистрированного в наложении (overlay) распознавания имён. При маршрутизации по именам распознавание содержимого зависит от области лавинной рассылки имён содержимого (т. е. сообщений о публикации и результирующих таблиц маршрутизации по именам. Например, при кэшировании содержимого маршрутизатор может уведомлять об этой информации лишь непосредственных соседей и только они смогут создавать записи на основе имён кэшированного содержимого. Если же соседние маршрутизаторы будут дальше распространять эту информацию, другие узлы также смогут направлять к кэшированной копии.

  • Влияние отказа узла. Узлы, вовлечённые в явное распознавание имён, имеют наложенные серверы распознавания (например, обработчики распознавания в DONA), а узлы, участвующие в маршрутизации по именам, являются маршрутизаторами, которые направляют сообщения на основе таблицы маршрутизации по именам (например, маршрутизаторы NDN). Отказ узла в системе явного распознавания может приводить к отказам некоторых запросов содержимого, которое не утратило доступности. Эта проблема не возникает при маршрутизации по именам, поскольку могут быть найдены пути обхода отказавших маршрутизаторов ICN при условии сохранения связности сети.

  • Поддерживаемые базы данных. Использование хранилища для явного распознавания имён отличается от случая маршрутизации по именам. Для явного распознавания имён обычно требуется поддержка двух баз данных – сопоставления имён с местоположением в наложении распознавания имён и таблицы маршрутизации в маршрутизаторах плоскости пересылки данных. В маршрутизации по именам достаточно лишь поддержки таблиц маршрутизации.

Кроме того, в распознавание имён может быть включён промежуточный шаг, а именно отображение имени на другие имена, чтобы упростить извлечение именованного содержимого через манифест [Westphal] [RFC8569]. Манифест распознаётся с помощью одного или двух описанных выше подходов и может включать дальнейшее сопоставление имён с содержимым и местоположением. Этапы распознавания имён становятся следующими – сначала транслируется имя манифеста в местоположение его копии, которая включает дополнительные имена компонентов содержимого и возможные места размещения содержимого, затем извлекается содержимое с помощью имён и/или местоположения, что может приводить к дополнительному распознаванию имён.

Таким образом, независимо от подхода, используемого NRS в ICN, распознавание имён является важной функцией, которая должна обеспечиваться инфраструктурой ICN.

3. Функциональность NRS в ICN

В этом разделе рассматривается функциональность NRS в ICN.

3.1. Поддержка разнотипных имён

В ICN имя служит для идентификации объекта данных и привязано к нему [RFC7927]. ICN требует уникальности и постоянства имени объекта данных для обеспечения доступности объекта в некой области. Есть разные подходы к разработке схем именования ICN [Bari]. В идеале имя может включать любую форму идентификатора, плоскую или иерархическую, понятную человеку или нечитаемую.

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

В PURSUIT [PURSUIT] имена являются плоскими и для NRS определены функции встречи (rendezvous), которые реализуются набором узлов встречи (rendezvous node или RN), называемых также сетью встреч (rendezvous network или RENE). Таким образом, имя состоит из цепочки идентификаторов областей действия (scope ID), а один идентификатор встречи (rendezvous ID) маршрутизируется узлами RN в сети RENE. В результате PURSUIT отделяет распознавание имён и маршрутизацию данных. Функции NRS выполняются сетью RENE.

В MobilityFirst [MF] имена, называемые глобально уникальными идентификаторами Global Unique Identifier или GUID), выводятся из понятных человеку имён через глобальную службу именования и являются «плоскими» типизованными строками размером 160 битов со свойствами самосертификации. MobilityFirst определяет глобальную службу распознавания имён (Global Name Resolution Service или GNRS), которая преобразует GUID в сетевые адреса и отделяет распознавание имён от маршрутизации данных аналогично PURSUIT.

В NetInf [Dannewitz] информационные объекты используют имена Named Information (NI) [RFC6920], состоящие из названия органа (authority) и дайджеста (хэш содержимого). Имена NI могут быть плоскими, поскольку часть authority необязательна. Архитектура NetInf также включает систему распознавания имён (NRS), которая может служить для преобразования NI в адреса нижележащего сетевого уровня с маршрутизацией.

В NDN [NDN] и CCNx [CCNx] имена являются иерархическими и могут быть похожи на URL. Каждый компонент имени может быть любым, включая понятные человеку строки или хэш-значения. В NDN/CCNx применяется маршрутизация по именам и маршрутизатор NDN пересылает запросы, выполняя поиск по наибольшему совпадению в базе данных пересылки (Forwarding Information Base FIB) для имени содержимого, а запросы хранятся в таблице ожидающих интересов (Pending Interest Table или PIT).

3.2. Поддержка мобильности издателей

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

Однако мобильность издателей не возникает автоматически из модели пересылки ICN, как мобильность потребителей. Если издатель перемещается в другое место сети или в другой домен, который управляется другим полномочным издателем, системе управления мобильностью будет сложно обновить базу маршрутной информации (Routing Information Base или RIB) и записи FIB в маршрутизаторах ICN, указав новый путь пересылки. Поэтому для различных вариантов архитектуры ICN в литературе предлагается принять NRS для обеспечения мобильности издателей. NRS можно реализовать разными способами, такими как точки встречи (rendezvous point) и/или наложенные системы отображения.

В NDN [Zhang2] для поддержки мобильности издателей были предложены механизмы встречи (rendezvous), организующие встречи по интересам (RV) с данными, создаваемыми мобильным издателем (mobile producer или MP). Здесь можно выделить на два подхода – «погоню» за мобильным издателем и данные встречи. В случае погони за MP встреча обеспечивает службу отображения, сопоставляющую имена данных от MP с именем текущей точки подключения MP (point of attachment или PoA). Дополнительно к этому RV выступает в качестве домашнего агента для поддержки IP mobility, поскольку RV позволяет туннелировать сообщения Interest от потребителей в направлении MP в точке PoA. В части данных встречи (rendezvous data) решение включает перенос данных, создаваемых MP, в хранилище (depot) вместо пересылки сообщений Interest. Таким образом, сообщение Interest от потребителя может пересылаться в стационарное место, называемое «встречей с данными» (data rendezvous), чтобы данные возвращались оттуда или извлекались из иного места с помощью отображения. В результате RV или иные функции отображения играют роль NRS в NDN.

В [Ravindran] используются метки пересылки (forwarding label или FL) для обеспечения возможности разделить пространства имён идентификаторов (ID) и местоположений (LID) в ICN. Обычно идентификаторы ID поддерживаются приложениями, а локаторы (местоположение) – администраторами сетей, так что ID сопоставляются с разнотипными схемами имён, а LID – с сетевыми доменами или конкретными элементами сети. Таким образом, объект FL выступает локатором (LID) и обеспечивает гибкость пересылки сообщений Interest через службы сопоставления между ID и LID. Поэтому в данном проекте служба сопоставления в инфраструктуре плоскости управления может рассматриваться как NRS.

В MobilityFirst [MF] мобильность потребителей и издателей может обрабатываться в основном глобальной службой распознавания имён (global name resolution service или GNRS), которая преобразует GUID в сетевые адреса. Поэтому требуется обновлять GNRS для поддержки мобильности, когда подключенный к сети объект меняет точку подключения, что отличается от NDN/CCNx.

В NetInf [Dannewitz] мобильность обслуживается NRS очень похожим на MobilityFirst способом.

Помимо мобильности потребителей и издателей в ICN возникает задача поддержки других динамических свойств, таких как множественные подключения (multi-homing), перенос (migration) и репликация именованных ресурсов (например, содержимого, устройств, служб). Следовательно, NRS может помочь в решении и этих динамических задач.

3.3. Поддержка расширяемой системы маршрутизации

В ICN имя объекта данных служит для маршрутизации на этапе распознавания или при поиске в таблице маршрутизации. Поэтому маршрутные сведения для каждого объекта данных следует поддерживать в маршрутных базах, таких как RIB и FIB. Поскольку число объектов данных будет очень велико, размер информационных баз также будет большим [RFC7927].

Иерархические пространства имён, применяемые в архитектуре CCNx [CCNx] и NDN [NDN] снижают размер таблиц за счёт агрегирования имён и повышают возможности расширения системы маршрутизации. Плоская же система имён существенно осложняет задачи расширения системы маршрутизации. Неагрегируемые префиксы имён, внедряемые в зону без принятого по умолчанию маршрута (Default Route Free Zone или DFZ) сети ICN могут создавать более серьёзные проблемы расширяемости по сравнению с аналогичными проблемами в системе маршрутизации IP. Таким образом, NRS может играть важную роль в смягчении проблемы расширяемости независимо от типа пространство имён.

В работе [Afanasyev] для решения задачи расширяемости маршрутизации в NDN DFZ применяется хорошо известная концепция сопоставления и инкапсуляции (map-and-encap), чтобы обеспечить простое и защищённое решение по сопоставлению пространств имён. В предложенном решении map-and-encap данные, у которых префиксов имён нет в таблице пересылки DFZ, можно получить с помощью распределенной системы сопоставления NDNS, которая обеспечивает поддержку и поиск данных отображения имён на глобально маршрутизируемые префиксы, играя роль NRS.

3.4. Поддержка кэширования вне пути

Кэширование в сети считается основным компонентом архитектуры ICN. Оно может применяться для обеспечения качества обслуживания (quality-of-service или QoS) пользователей с целью снижения общего трафика, предотвращения перегрузок и атак на службы (denial-of-service или DoS), а также улучшения доступности. Кэширование можно разделить на внутрипутевое (on-path) и внешнее (off-path) в зависимости от размещения кэша относительно пути от исходного сервера к потребителю. Внешнее кэширование, которое называют также репликацией (content replication) или сохранением (content storing) содержимого, предназначено для репликации содержимого в сети с целью повышения уровня доступности независимо от местоположения по отношению к пути пересылки. Поиск кэшированных объектов вне пути является нетривиальной задачей в ICN с маршрутизацией по именам. Для поддержки внешнего кэширования реплики обычно анонсируются в систему маршрутизации по именам или в NRS.

В [Bayhan] распознавание имён (NRS) служит для поиска копий вне пути через сеть, которые могут быть недоступны для механизмов маршрутизации по именам. Такая возможность может быть полезна в автономной системе (Autonomous System или AS) для предотвращения дорогостоящего трафика между AS к внешнему содержимому, повышения эффективности использования пропускной способности для внутреннего трафика AS и снижения задержки доступа к данным для пользователей.

3.5. Поддержка безымянных объектов

В CCNx 1.0 [Mosko2] концепция Nameless Object, которые представляют собой безымянные объекты содержимого (Content Object), введена для обеспечения возможности перемещать содержимое между хранилищами реплик без переименования или повторного подписывания объектов с новым именем. К безымянным объектам можно обращаться по хэш-значению ContentObjectHash на основе алгоритма SHA-256.

Сообщения Interest будут содержать имя и ContentObjectHash – имя будет служить для маршрутизации, а ContentObjectHash – для сопоставления. Однако на обратном пути при отсутствии имени Content Object объект будет безымянным и сопоставление будет возможно лишь по ContentObjectHash. Поэтому потребителю потребуется распознавать имя и хэш через внешнюю систему, которую можно рассматривать как NRS.

3.6. Манифест поддержки

Для коллекций объектов данных, организованных в большие файлоподобные структуры [FLIC] применяются манифесты в качестве структур данных для передачи информации. Манифест может содержать хэш-дайджесты подписанных Content Object или других манифестов, так что большие объекты содержимого, представляющие крупные части данных приложения, могут быть собраны с использованием такого манифеста.

Для запроса Content Object потребителю нужно знать имя корня манифеста для получения этого манифеста. В случае файлоподобных коллекций FLIC (File-Like ICN Collection) имя манифеста может быть представлено безымянным корневым манифестом, чтобы можно было задействовать для предоставления информации потребителю внешние системы, такие как NRS.

3.7. Метаданные поддержки

При распознавании имени Content Object служба NRS может возвращать множество метаданных в дополнение к местоположению объекта. Метаданные могут включать дополнительное местоположение, поддерживаемые протоколы передачи, правила кэширования, параметры защиты, формат данных, хэш объекта и пр. Потребитель может использовать метаданные для выбора протокола передачи, механизмов защиты, выходного интерфейса и т. п. Пример такого использования метаданных даёт архитектура сетевых объектов (Networked Object или NEO) в ICN [NEO].

4. Вопросы проектирования NRS и ICN

В этом разделе приведены соображения об устройстве и проектировании NRS в ICN.

4.1. Время отклика при распознавании

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

Приемлемая задержка отклика может составлять время порядка интервала кругового обхода (round-trip) между запросившим клиентом и обеспечивающим отклик сервером NRS. Хотя значения RTT могут существенно зависеть от удалённости указанных точек, следует использовать ту или иную верхнюю границу. Верхняя граница задержки отклика должна гарантироваться в некоторых приложениях, чувствительных к задержкам, например в промышленных системах или телемедицине.

Время отклика учитывает все этапы распознавания, включая возможное поэтапное (hop-by-hop) распознавание или иерархическую пересылку запроса.

4.2. Точность распознавания

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

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

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

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

4.3. Гарантии распознавания

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

4.4. Беспристрастность распознавания

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

Отдано следует отметить, что содержимое (или его издатель) может требовать от сети иного уровня QoS (см., например, [RFC9064]) и это может затрагивать NRS, поэтому в таких случаях беспристрастность может обеспечиваться в рамках одного класса обслуживания.

4.5. Расширяемость

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

Система NRS должна расширяться с ростом числа частей (имён) содержимого и следует поддерживать очень большой каталог содержимого. Трафик Internet измеряется зеттабайтами (1021 байт) в год. Поскольку служба NRS связана с фактическим трафиком, число имён содержимого будет расти с увеличением трафика. Размер содержимого может варьироваться от нескольких байтов до гигабайт, поэтому в NRS следует предполагать в ближайшем будущем расширение каталога до 1021 и более.

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

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

Системе NRS следует расширять свои возможности реагирования при росте числа запросов, которые ожидаются от таких приложений, как IoT или межмашинные взаимодействия (machine-to-machine или M2M), где запросы и обмен данными происходят часто.

4.6. Управляемость

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

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

4.7. Развёрнутая система

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

4.8. Отказоустойчивость

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

При отказе сервера NRS система NRS должна быть способна восстановить и/или возобновить записи, хранившиеся на этом сервере NRS.

4.9. Безопасность и приватность

При использовании NRS в ICN возникают некоторые вопросы безопасности для серверов и узлов NRS, а также хранящихся в системе NRS записей распознавания имён. Эти вопросы рассматриваются ниже.

4.9.1. Конфиденциальность

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

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

NRS может поддерживать механизмы запутывания (obfuscation) и/или шифрования, чтобы содержимое запросов на распознавание не было доступно сторонним лицам вне системы NRS.

Система NRS должна сохранять конфиденциальность для предотвращения несанкционированного доступа к записям сопоставления имён. Это может требоваться в средах IoT где создаётся много «деликатных» данных.

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

4.9.2. Проверка подлинности

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

  • Аутентификация издателей. Система NRS должна поддерживать проверку подлинности издателей содержимого, чтобы обновление, добавление, удаление записей сопоставления имён, запрашиваемые издателями, были действительны, а издатели имели полномочия на изменение (отзыв) или добавление записей.

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

4.9.3. Целостность

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

4.9.4. Отказоустойчивость и доступность

Системе NRS следует быть устойчивой к атакам на службы (denial-of-service) и другим распространенным атакам, чтобы предотвратить косвенное нарушение работы всей системы. Поэтому при отказе части системы NRS отказ следует изолировать без влияния на другие домены. Для возобновления нормальной работы службы нужны механизмы быстрого восстановления.

5. Заключение

Маршрутизация ICN может состоять из 3 этапов – распознавание имени, маршрутизация запроса содержимого и доставка содержимого. В этом документе описан этап распознавания имён, который является первым и наиболее важным для успешной маршрутизации в ICN. Сервис распознавания имён (NRS) в ICN определён как служба, обеспечивающая функцию распознавания имён для трансляции имени объекта в иную информацию, такую как местоположение (locator), иное имя, метаданные, следующий этап пересылки (next-hop) и т. п., которая может применяться для пересылки к интересующему объекту.

Документ классифицирует и анализирует подходы к реализации NRS в зависимости от использования явного или неявного процесса распознавания при маршрутизации. Документ также разъясняет функции NRS для поддержки разных типов имён, мобильности издателей, расширяемости системы маршрутизации, кэширования вне пути, безымянных объектов, манифестов и метаданных. Приведены также соображения по использованию NRS в ICN, включая время отклика и точность, гарантии и беспристрастность распознавания, расширяемость и управляемость, развёртывание системы и устойчивость к отказам.

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

Документ не требует действий IANA.

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

Рекомендации по безопасности приведены в параграфе 4.9.

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

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

[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, “Information-Centric Networking (ICN) Research Challenges”, RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.

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

[Afanasyev] Afanasyev, A. et al., “SNAMP: Secure Namespace Mapping to Scale NDN Forwarding”, 2015 IEEE Conference on Computer Communications Workshops, DOI 10.1109/INFCOMW.2015.7179398, April 2015, <https://doi.org/10.1109/INFCOMW.2015.7179398>.

[Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., and B. Ohlman, “A Survey of Information-Centric Networking”, IEEE Communications Magazine, Vol. 50, Issue 7, DOI 10.1109/MCOM.2012.6231276, July 2012, <https://doi.org/10.1109/MCOM.2012.6231276>.

[Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, “Named data networking for IoT: An architectural perspective”, European Conference on Networks and Communications (EuCNC), DOI 10.1109/EuCNC.2014.6882665, June 2014, <https://doi.org/10.1109/EuCNC.2014.6882665>.

[Amadeo2] Amadeo, M. et al., “Information-centric networking for the internet of things: challenges and opportunities”, IEEE Network, Vol. 30, No. 2, DOI 10.1109/MNET.2016.7437030, March 2016, <https://doi.org/10.1109/MNET.2016.7437030>.

[Baccelli] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. Wählisch, “Information Centric Networking in the IoT: Experiments with NDN in the Wild”, ACM-ICN 2014, DOI 10.1145/2660129.2660144, 2014, <https://doi.org/10.1145/2660129.2660144>.

[Bari] Bari, M.F., Chowdhury, S.R., Ahmed, R., Boutaba, R., and B. Mathieu, “A Survey of Naming and Routing in Information-Centric Networks”, IEEE Communications Magazine, Vol. 50, No. 12, pp. 44-53, DOI 10.1109/MCOM.2012.6384450, December 2012, <https://doi.org/10.1109/MCOM.2012.6384450>.

[Bayhan] Bayhan, S. et al., “On Content Indexing for Off-Path Caching in Information-Centric Networks”, ACM-ICN 2016, DOI 10.1145/2984356.2984372, September 2016, <https://doi.org/10.1145/2984356.2984372>.

[CCNx] “CICN”, <https://wiki.fd.io/view/Cicn>.

[Dannewitz] Dannewitz, C. et al., “Network of Information (NetInf) – An information-centric networking architecture”, Computer Communications, Vol. 36, Issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.009>.

[FLIC] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, “File-Like ICN Collections (FLIC)”, Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-03, 7 November 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03>.

[ID.Zhang2] Ravindran, R., Zhang, Y., Grieco, L. A., Lindgren, A., Burke, J., Ahlgren, B., and A. Azgin, “Design Considerations for Applying ICN to IoT”, Work in Progress, Internet-Draft, draft-irtf-icnrg-icniot-03, 2 May 2019, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-03>.

[Jung] Jung, H. et al., “IDNet: Beyond All-IP Network”, ETRI Journal, Vol. 37, Issue 5, DOI 10.4218/etrij.15.2415.0045, October 2015, <https://doi.org/10.4218/etrij.15.2415.0045>.

[Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, K.H., Shenker, S., and I. Stoica, “A Data-Oriented (and Beyond) Network Architecture”, ACM SIGCOMM 2007, pp. 181-192, DOI 10.1145/1282380.1282402, August 2007, <https://doi.org/10.1145/1282380.1282402>.

[MF] “MobilityFirst Future Internet Architecture Project Overview”, <http://mobilityfirst.winlab.rutgers.edu>.

[Mosko2] Mosko, M., “Nameless Objects”, IRTF ICNRG, January 2016, <https://datatracker.ietf.org/meeting/interim-2016-icnrg-01/materials/slides-interim-2016-icnrg-1-7.pdf>.

[NDN] “Named Data Networking”, <http://www.named-data.net>.

[NEO] Eriksson, A. and A.M. Malik, “A DNS-based information-centric network architecture open to multiple protocols for transfer of data objects”, 21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), pp. 1-8, DOI 10.1109/ICIN.2018.8401595, February 2018, <https://doi.org/10.1109/ICIN.2018.8401595>.

[NRSarch] Hong, J., You, T., and V. Kafle, “Architectural Considerations of ICN using Name Resolution Service”, Work in Progress, Internet-Draft, draft-irtf-icnrg-nrsarch-considerations-06, 12 February 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-nrsarch-considerations-06>.

[PURSUIT] “FP7 PURSUIT”, <https://www.fp7-pursuit.eu/>.

[Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, “A case for ICN usage in IoT environments”, IEEE GLOBECOM, DOI GLOCOM.2014.7037227, December 2014, <https://doi.org/GLOCOM.2014.7037227>.

[Ravindran] Ravindran, R., Chakraborti, A., and A. Azgin, “Forwarding Label support in CCN Protocol”, Work in Progress, Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02>.

[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, “Naming Things with Hashes”, RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.

[RFC8569] Mosko, M., Solis, I., and C. Wood, “Content-Centric Networking (CCNx) Semantics”, RFC 8569, DOI 10.17487/RFC8569, July 2019, <https://www.rfc-editor.org/info/rfc8569>.

[RFC9064] Oran, D., “Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols”, RFC 9064, DOI 10.17487/RFC9064, June 2021, <https://www.rfc-editor.org/info/rfc9064>.

[SA2-5GLAN] 3GPP, “New WID: 5GS Enhanced support of Vertical and LAN Services”, TSG SA Meeting #SP-82, December 2018, <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181120.zip>.

[SAIL] “Scalable and Adaptive Internet Solutions (SAIL)”, <http://www.sail-project.eu/>.

[Westphal] Westphal, C. and E. Demirors, “An IP-Based Manifest Architecture for ICN”, ACM-ICN 2015, DOI 10.1145/2810156.2812614, September 2015, <https://doi.org/10.1145/2810156.2812614>.

[Xylomenos] Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., Tsilopoulos, C., Vasilakos, X., Katsaros, K., and G. Polyzos, “A Survey of Information-Centric Networking Research”, IEEE Communications Surveys and Tutorials, Vol. 16, Issue 2, DOI 10.1109/SURV.2013.070813.00063, 2014, <https://doi.org/10.1109/SURV.2013.070813.00063>.

[Zhang2] Zhang, Y. et al., “A Survey of Mobility Support in Named Data Networking”, IEEE Conference on Computer Communications Workshops, DOI 10.1109/INFCOMW.2016.7562050, April 2016, <https://doi.org/10.1109/INFCOMW.2016.7562050>.

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

Авторы благодарны Dave Oran, Dirk Kutscher, Ved Kafle, Vincent Roca, Marie-Jose Montpetit, Stephen Farrell, Mirja Kühlewind, Colin Perkins за полезные рецензии, комментарии и улучшения для документа.

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

Jungha Hong
ETRI
Yuseung-Gu
218 Gajeong-ro
Daejeon
34129
Republic of Korea
Email: jhong@etri.re.kr
 
Tae-Wan You
ETRI
Yuseung-Gu
218 Gajeong-ro
Daejeon
34129
Republic of Korea
Email: twyou@etri.re.kr
 
Lijun Dong
Futurewei Technologies Inc.
10180 Telesis Court
San Diego, CA 92121
United States of America
Email: lijun.dong@futurewei.com
 
Cedric Westphal
Futurewei Technologies Inc.
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: cedric.westphal@futurewei.com
 
Börje Ohlman
Ericsson Research
SE-16480 Stockholm
Sweden
Email: Borje.Ohlman@ericsson.com

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

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

nmalykh@protokols.ru

1Information-Centric Networking Research Group – группа по исследованию ориентированных на информацию сетей.

2Internet Research Task Force – комиссия по исследованиям Internet.

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

RFC 8911 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 с двумя экземпля