RFC 8947 Link-Layer Address Assignment Mechanism for DHCPv6

image_print
Internet Engineering Task Force (IETF)                           B. Volz
Request for Comments: 8947                                         Cisco
Category: Standards Track                                   T. Mrugalski
ISSN: 2070-1721                                                      ISC
                                                           CJ. Bernardos
                                                                    UC3M
                                                           December 2020

Link-Layer Address Assignment Mechanism for DHCPv6

Механизм назначения адресов канального уровня для DHCPv6

PDF

Аннотация

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

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

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

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

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

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

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

Имеется несколько типов развертывания, где нужно инициализировать большое число устройств. Одним из них являются системы с большим числом создаваемых виртуальных машин (VM). Обычно новым экземплярам VM назначаются адреса канального уровня, но случайное назначение не обеспечивает нужной расширяемости в силу риска совпадения адресов (см. Приложение A.1 к [RFC4429]). Другой вариант связан с устройствами «Интернета вещей» (Internet of Things или IoT) [RFC7228]. Огромное число таких устройств может исчерпать глобальное пространство адресов IEEE OUI3. Хотя глобальная уникальность таких адресов обычно не требуется, нужно предотвращать конфликты адресов в рамках административного домена. Поэтому желательно иметь тот или иной механизм, который обеспечит в локальном масштабе уникальность адресов MAC4.

В этом документе предложен новый механизм расширяющий DHCPv6 для распределения адресов канального уровня.

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

Хотя в документе описано решение, применимое к любому типу адресов канального уровня, некоторые детали связаны с 48-битовыми MAC-адресами IEEE 802 [IEEEStd802]. Документы для иных адресов могут быть созданы в будущем.

Комитет IEEE 802 изначально выделил половину пространства 48-битовых адресов MAC для локального применения (бит U/L5 имеет значение 1). В 2017 г. IEEE была опубликована поправка [IEEEStd802c], разделяющая пространство адресов на квадранты с разными правилами, которые описаны в Приложении A.

В IEEE также разрабатываются протоколы и процедуры для назначения уникальных в локальном масштабе адресов (IEEE 802.1CQ). Эта работа может обеспечить дополнительный вариант назначения адресов. Дополнительную информацию можно найти в [IEEE-P802.1CQ-Project].

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

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

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

В документе используются относящиеся к задаче термины DHCP из [RFC8415]. Ниже приведены определения терминов, которые отличаются от указанного документа или введены заново.

address – адрес

Если явно не указано иное, это адрес канального уровня (MAC-адрес) [IEEEStd802]. Обычно адрес имеет размер 6 октетов, но иногда применяются другие размеры.

address block – блок адресов

Множество последовательных адресов канального уровня. Блок указывается первым адресом и числом дополнительно выделяемых адресов. Один адрес можно представить блоком из этого адреса и 0 дополнительных.

client – клиент

Узел, заинтересованный в получении адреса канального уровня. Он реализует базовые механизмы DHCP, описанные в [RFC8415], и поддерживает новые опции, заданные этим документом (IA_LL и LLADDR). Клиент может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

IA_LL

Identity Association для Link-Layer Address – ассоциация отождествления (IA – identity association), используемая для запроса или назначения адресов канального уровня (параграф 11.1).

LLADDR

Опция адреса канального уровня, используемая для запроса или назначения блока адресов (параграф 11.2).

server – сервер

Узел, который поддерживает назначение адресов канального уровня и способен отвечать на запросы клиентов. Узел реализует базовую функциональность сервера DHCP [RFC8415] и поддерживает новые опции, заданные этим документом (IA_LL и LLADDR). Сервер может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

4. Варианты развертывания

Механизм предназначен на роль базового и приемлемого в разных системах, но имеется два основных варианта, где механизм пытается решить задачу назначения адресов – (i) режим прокси-клиента (proxy client) и (ii) режим прямого клиента (direct client).

4.1. Режим прокси-клиента

Этот режим применяется в тех случаях, когда выступающий клиентом DHCP элемент запрашивает у доступных серверов DHCP один или множество (блок) адресов для последующего распределения конечным устройствам. Большие системы с виртуализацией являются примером использования прокси-клиентов. В таких средах запрашивающий адреса элемент часто называется гипервизором и он зачастую нужен для создания новых VM, которым гипервизор должен назначать новые адреса. Гипервизор сам не использует полученные адреса, а распределяет их создаваемым VM. Следует отметить кумулятивных характер этого режима – гипервизор скорей всего будет позднее запрашивать дополнительные адреса. Адреса удаленных VM могут применяться для новых.

4.2. Режим прямого клиента

Этот режим применяется в тех случаях, когда выступающий клиентом DHCP элемент запрашивает у доступных серверов DHCP один или множество (блок) адресов для своих нужд. Этот вариант связан с IoT (раздел 1). При первой загрузке устройство использует для каждого интерфейса временный адрес, как описано в [IEEEStd802.11] и IEEE 802.1CQ [IEEE-P802.1CQ-Project], для отправки начальных пакетов DHCP доступным серверам DHCP, у которых клиент запрашивает 1 адрес для данного интерфейса. После получения такого адреса устройство отбрасывает (забывает) временный адрес и пользуется полученным (арендованным).

Отметим, что работающий в соответствии с приведенным описанием клиент не имеет глобально уникального адреса ни на одном из своих интерфейсов и ему недопустимо применять основанный на канальном уровне идентификатор DUID (DHCP Unique Identifier), описанный в разделе 11 [RFC8415]).

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

5. Обзор механизма

В описанных в разделе 4 вариантах протокол работает в основном одинаково. Устройство, запрашивающее адрес, действуя в качестве клиента DHCP, передает сообщение Solicit с опцией IA_LL всем доступным серверам DHCP. Эта опция IA_LL должна включать опцию LLADDR, указывающую link-layer-type и link-layer-len, а также может задавать желаемый адрес или блок в качестве совета серверу. Каждый из доступных серверов отвечает сообщением Reply с подтвержденными адресами (если было запрошено и выполнено Rapid Commit) или сообщением Advertise с предложенными адресами. Клиент выбирает отклик в соответствии с [RFC8415]. При необходимости клиент передает сообщение Request, по которому сервер назначит адреса и передаст их в сообщении Reply. После приема сообщения Reply клиент может начать использование полученных адресов.

Используются обычные механизмы DHCP. Предполагается, что клиент периодически обновляет адреса в соответствии с таймерами T1 и T2 и прекращает использовать адрес по истечении срока его действия. Обновление может быть запрещено сервером административно путем установки бесконечного значения (infinity) для таймеров T1 и T2 (см. параграф 7.7 в [RFC8415]). Администратор может сделать выделенные адреса постоянными, указав бесконечный (infinity) срок действия, как указано в параграфе 7.7 [RFC8415].

Клиент может освободить адреса, когда они не нужны, передав сообщение Release (см. параграф 18.2.7 в [RFC8415]).

На рисунке 9 в [RFC8415] показана временная диаграмма обмена сообщениями между клиентом и двумя серверами для типичного срока действия одной или нескольких аренд.

Сообщения Confirm и Information-request не применяются при назначении адресов канального уровня. Сообщение Decline технически требоваться не должно, но в разделе 12 описан случай, где такое сообщение требуется.

Использующим этот механизм клиентам следует задавать опцию Rapid Commit, как указано в параграфах 5.1 и 18.2.1 [RFC8415], для получения адресов в результате обмена лишь двумя сообщениями, когда это возможно.

Устройства, поддерживающие это предложение, могут поддерживать также механизм реконфигурации, описанный в параграфе 18.2.11 [RFC8415]. Если механизм реконфигурации поддерживается клиентом и сервером, он позволяет администратору своевременно уведомлять клиентов об изменении конфигурации и инициировать незамедлительное получение соответствующих изменений, не ожидая таймера T1. Поскольку для этого механизма нужна реализация протокола Reconfiguration Key Authentication (раздел 20.4 в [RFC8415]), мелкие устройства могут не поддерживать его.

6. Допущения

Одним из важных свойств механизма является его кумулятивная природа, особенно при работе с гипервизором. Отношения «клиент-сервер» не похожи на другие транзакции DHCP в сценарии с гипервизором. В типичной среде будет использоваться один сервер и небольшое (возможно 1) число гипервизоров. Однако с течением времени число запрашиваемых гипервизором адресов будет расти по мере создания VM.

Другим аспектом, важным для эффективного проектирования, является то, что один клиент-гипервизор вероятно будет использовать тысячи адресов. Подход, аналогичный применяемому при назначении адресов или префиксов IPv6 (контейнер IA со списком назначенных адресов, по одной записи на адрес), здесь работать не будет. Поэтому механизм должен работать не с отдельными адресами, а с их блоками. При этом отдельный адрес считается просто блоком с одним адресом.

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

7. Представление информации

Клиент должен передавать опцию LLADDR, инкапсулированную в опцию IA_LL, для задания значений link-layer-type и link-layer-len. Для link-layer-type 1 (Ethernet) и 6 (IEEE 802 Networks) клиент устанавливает поле link-layer-address как показано ниже.

  1. Все 0, если клиент не указывает начального адреса блока индивидуальных адресов. В таких адресах бит IEEE 802 individual/group имеет значение 0 (индивидуальный).

  2. Любое другое значение указывате начальный адрес запрашиваемого блока.

Представление других link-layer-type может быть добавлено в новых RFC.

Клиент указывает в поле extra-addresses значение 0 (один адрес) или размер запрашиваемого блока минус 1.

Клиент должен установить valid-lifetime = 0 (сервер должен игнорировать это поле).

8. Запрос адреса

Адреса выделяются блоками с минимальным размером 1. Для запроса адресов клиент передает сообщение Solicit с опцией IA_LL, которая должна включать опцию LLADDR, как указано в разделе 7.

Сервер при получении опции IA_LL проверяет ее содержимое и может предложить адрес или адреса для каждой опции LLADDR в соответствии со своими правилами. Сервер может учитывать блок адресов, запрошенный клиентом в опции LLADDR. Однако сервер может игнорировать все или часть параметров, запрошенного блока адресов. В частности, сервер может выделить другой начальный адрес или меньшее число адресов в блоке. Сервер передает в ответ сообщение Advertise с опцией IA_LL, содержащей опцию LLADDR, которая указывает предложенные адреса. Если сервер не способен выделить адреса, он должен передать опцию IA_LL с опцией Status Code (см. параграф 21.13 в [RFC8415]), указывающей NoAddrsAvail.

Отметим, что сервер, не поддерживающий опцию IA_LL, будет игнорировать ее и не будет возвращать сообщение Advertise (и Reply). Передающий опции IA_LL клиент должен рассматривать это как возврат сервером статуса NoAddrsAvail для этих опций IA_LL.

Клиент ждет от доступных серверов отклики Advertise и выбирает один сервер, как указано в параграфе 18.2.9 [RFC8415]. Затем клиент передает сообщение Request с контейнером IA_LL, содержащим опцию LLADDR, скопированную из сообщения Advertise от выбранного сервера.

Клиент должен обрабатывать блок адресов из сообщения Advertise, а не тот, который он передавал в сообщении Solicit, и может учитывать предложенные адреса при выборе сообщения Advertise. Сервер может предложить меньшее число адресов или блок, отличающихся от запрошенного. Клиенту недопустимо использовать ресурсы, указанные в сообщении Advertise, для каких-либо целей, кроме выбора сервера и включения данных в сообщение Request для этого сервера. Доступные клиенту ресурсы будут возвращены в сообщении Reply.

При получении сообщения Request с контейнером опции IA_LL сервер выделяет запрошенные адреса в соответствии с настроенными на нем правилами. Сервер может выделить другой (или меньший) блок, нежели указано в сообщении Request. Затем сервер создает и отправляет клиенту сообщение Reply.

При получении сообщения Reply клиент анализирует контейнер опции IA_LL и может начать использование предоставленных адресов. Клиент должен заново запустить таймеры T1 и T2, используя значения из опции IA_LL.

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

Клиент, включивший опцию Rapid Commit в сообщение Solicit, может получить ответное сообщение Reply и пропустить описанные выше этапы с сообщениями Advertise и Request (см. параграф 18.2.1 в [RFC8415]).

Клиенту, меняющему адрес канального уровня на своем интерфейсе, следует выполнять рекомендации параграфа 7.2.6 [RFC4861] для быстрого информирования своих соседей о новом адресе канального уровня.

9. Обновление адреса

Обновление адресов выполняется по обычной процедуре DHCP, описанной в параграфе 18.2.4 [RFC8415]. По завершении времени T1 клиент начинает отправку сообщений Renew с опцией IA_LL, содержащей опцию LLADDR для обновляемого блока адресов. Сервер отвечает сообщением Reply с обновленным блоком адресов. Серверу недопустимо сокращать или расширять блок адресов. Когда блок адресов назначен и имеет ненулевой срок действия, его размер, начальный и конечный адрес менять недопустимо.

Если запрашивающему клиенту нужны дополнительные адреса (например, гипервизору нужны адреса для новых VM), он должен отправить опцию IA_LL с другим идентификатором отождествления (IAID – Identity Association IDentifier) для создания другого «контейнера» с дополнительными адресами.

Если клиент не способен обновить адреса к моменту T2, он начинает передачу сообщений Rebind, как описано в параграфе 18.2.5 [RFC8415].

10. Освобождение адреса

Клиент может принять решение об освобождении выделенных ему адресов. Клиент должен освобождать выделенный блок целиком. Для освобождения блока клиент передает сообщение Release с опцией IA_LL, содержащей опцию LLADDR для освобождаемого блока адресов. Механизм передачи Release описан в параграфе 18.2.7 [RFC8415].

Отметим, что клиент, освобождающий свой адрес канального уровня, должен прекратить его использование до отправки сообщения Release (как указано в [RFC8415]) и для отправки сообщения Release клиент должен использовать иной адрес (например, тот, который применялся при инициировании DHCPv6 для получения выделенного адреса канального уровня).

11. Определения опций

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

11.1. Опция IA_LL

Опция IA_LL (Identity Association for Link-Layer Addresses6) служит для передачи параметров и адресных блоков, связанных с IA_LL. Формат опции показан на рисунке 1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          OPTION_IA_LL         |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        IAID (4 октета)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          T1 (4 октета)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          T2 (4 октета)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                         IA_LL-options                         .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Формат опции IA_LL.


option-code

OPTION_IA_LL (138).

option-len

12 + размер поля IA_LL-options.

IAID

Уникальный идентификатор для данной опции IA_LL. Значение IAID должно быть уникальным среди всех IA_LL этого клиента. Пространство номеров для IA_LL IAID отделено от пространства номеров других типов опций IA (IA_NA, IA_TA и IA_PD). Выражается 4-октетным целым числом без знака.

T1

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

T2

Временной интервал, по истечении которого клиенту следует контактировать с любым доступным сервером для расширения срока действия адресов, назначенных в IA_LL. T2 указывается в секундах относительно текущего времени 4-октетным целым числом без знака.

IA_LL-options

Опции, связанные с данной опцией IA_LL. Поле имеет переменный размер (на 12 меньше значения option-len).

Опция IA_LL может указыватьмя лишь в области опций сообщения DHCP. Можно включать в сообщение DHCP несколько опций IA_LL, каждая из которых должна иметь уникальное значение IAID.

Статус операций, связанных с этой опцией IA_LL, указывается в опции Status Code (раздел 21.13 в [RFC8415]) поля IA_LL-options.

Отметим, что IA_LL не имеет явного срока действия (lifetime или lease length). Когда истекает срок действия всех адресов в IA_LL, можно считать IA_LL просроченной. Параметры T1 и T2 дают серверам явный контроль над повторными контактами клиента с сервером для конкретной опции IA_LL. В сообщении от клиента поля T1 и T2 должны иметь значение 0. Сервер должен игнорировать значения этих полей в сообщениях от клиентов. Клиент должен использовать значения полей T1 и T2 из сообщения от сервера для таймеров T1 и T2, если эти значения отличны от 0. Поля T1 и T2 указывают значения одноименных таймеров в секундах. В соответствии с разделом 7.7 [RFC8415], значение 0xffffffff указывает «бесконечный» (infinity) срок действия и должно применяться с осторожностью.

Сервер выбирает значения T1 и T2, чтобы позволить клиенту расширить срок действия блоков адресов в IA_LL, даже если сервер недоступен в течение короткого промежутка времени. Для T1 и T2 рекомендуются значения 0,5 и 0,8 от кратчайшего срока действия блока адресов в IA, который сервер желает продлить. Если «кратчайший» срок действия задан значением 0xffffffff (неограничен), для T1 и T2 также рекомендуется значение 0xffffffff. Если выбор времени обновления адресов в IA_LL следует оставить за клиентом, сервер устанавливает в T1 и T2 значение 0. Клиент должен следовать правилам, указанным в параграфе 14.2 [RFC8415].

Если клиент получает IA_LL с T1 > T2 > 0, он отбрасывает опцию IA_LL и обрабатывает остальное сообщение как будто в нем нет опции IA_LL.

Поле IA_LL-options обычно включает одну или множество опций LLADDR (см. раздел 11.2). Если клиент не включил опцию LLADDR в сообщение Solicit или Request, сервер должен считать это запросом одного адреса без рекомендованного клиентом значения.

11.2. Опция LLADDR

Опция адресов канального уровня (LLADDR – Link-Layer Addresses) служит для указания блока адресов, связанного с IA_LL. Опция должна инкапсулироваться в поле IA_LL-options опции IA_LL, включающее опции, относящиеся к данному блоку адресов. Формат опции показан на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        OPTION_LLADDR          |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       link-layer-type         |        link-layer-len         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                     link-layer-address                        .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      extra-addresses                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      valid-lifetime                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                      LLaddr-options                           .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат опции LLADDR.


option-code

OPTION_LLADDR (139).

option-len

12 + значение поля link-layer-len + размер поля LLaddr-options. В предположении 6-битовых значений link-layer-address и отсутствия дополнительных опций поле option-len будет иметь значение 18.

link-layer-type

Поле link-layer-type должно указывать действительный тип оборудования, выделенный IANA, как описано в [RFC5494], и включенный в реестр Hardware Types, доступный по ссылке https://www.iana.org/assignments/arp-parameters. Значение является 2-октетным целым числом без знака.

link-layer-len

Задает размер поля link-layer-address в октетах (обычно 6 для link-layer-type = 1 (Ethernet) и 6 (IEEE 802 Networks)). Это поле включено с учетом канальных уровней, которые могут использовать адреса переменного размера. Значение является 2-октетным целым числом без знака.

link-layer-address

Задает первый адрес канального уровня, который запрашивается или выделяется (в зависимости от сообщения). Клиент может передать специальное значение для запроса любого адреса. Для link-layer-type 1 и 6 подробности приведены в разделе 7. Поле имеет размер link-layer-len.

extra-addresses

Задает число дополнительных адресов, следующих за указанным полем link-layer-address. Для выделения одного адреса используется значение 0. Например, при указании link-layer-address 02:04:06:08:0a и extra-addresses 3 будет назначаться 4 адреса, начиная с 02:04:06:08:0a и заканчивая 02:04:06:08:0d (включительно). Значение является 4-октетным целым числом без знака.

valid-lifetime

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

LLaddr-options

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

В сообщении от клиента поле valid-lifetime должно иметь значение 0, сервер должен игнорировать значение поля.

Клиент должен использовать значение valid-lifetime из сообщения от сервера для установки срока действия блока адресов. Поле задает число секунд, в течение которого адреса блока будут действительны.

В соответствии с разделом 7.7 [RFC8415] valid-lifetime со значением 0xffffffff задает неограниченный срок действия адресов (infinity) и следует использовать это значение с осторожностью.

В опцию IA_LL можно включать более одной опции LLADDR.

12. Выбор адресов канального уровня для назначения IA_LL

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

Адреса канального уровня обычно зависят от типа соединения и серверу следует выполнять процедуры раздела 13.1 в [RFC8415] для определения типа клиентского канала.

Для адресов IEEE 802 MAC ([IEEEStd802] с дополнением [IEEEStd802c]) процедура выбора описана ниже.

  1. Администратору сервера следует соблюдать спецификации IEEE 802 в части пулов индивидуальных адресов, доступных для назначения (см. Приложение A и [IEEEStd802c]). Распределять можно лишь адресное пространство, выделенное для локального использования, или при наличии полномочий назначать иные адреса.

  2. Для серверов недопустимо позволять администратору настраивать пул адресов, который будет пересекать границу 242 битов (для 48-битовых адресов MAC), чтобы предотвратить проблемы при изменении первого октета адреса и специальных битов в нем (Приложение A). Клиенты должны отвергать назначения, в которых блок пересекает эту границу (клиент должен отвергать назначение, см. параграф 18.2.8 в [RFC8415]).

  3. Сервер может использовать опции, представленные ретранслятором или клиентом, для выбора квадранта (Приложение A), из которого будут назначаться адреса. Это могут быть опции из [RFC8948].

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

Агентство IANA выделило код опции OPTION_IA_LL (138) из субреестра Option Codes в реестре Dynamic Host Configuration Protocol for IPv6 (DHCPv6), доступном по ссылке http://www.iana.org/assignments/dhcpv6-parameters.

   Value:        138
   Description:  OPTION_IA_LL
   Client ORO:   No
   Singleton Option:  No
   Reference:    RFC 8947

Агентство IANA выделило код опции OPTION_LLADDR (139) из субреестра Option Codes в реестре Dynamic Host Configuration Protocol for IPv6 (DHCPv6), доступном по ссылке http://www.iana.org/assignments/dhcpv6-parameters.

   Value:        139
   Description:  OPTION_LLADDR
   Client ORO:   No
   Singleton Option:  No
   Reference:    RFC 8947

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

Вопросы безопасности DHCP рассмотрены в разделе 22 [RFC8415] и разделе 23 [RFC7227], для IPv6 -в [RFC8200].

В разделе 22 [RFC8415] отмечено:

В DHCP отсутствует сквозное шифрование между клиентами и серверами, что открывает возможность для атак с захватом, подменой и прослушиванием трафика.

В некоторых средах можно обеспечить защиту на основе рекомендаций раздела 22 в [RFC8415].

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

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

15. Вопросы конфиденциальности

Вопросы конфиденциальности DHCP рассмотрены в разделе 23 [RFC8415].

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

Как отмечено в разделе 23 [RFC8415], серверам DHCP и гипервизорам может потребоваться учитывать влияние последовательного выделения адресов. Хотя в общем случае относится лишь к локальным соединениям в отличие от назначения адресов и префиксов IPv6, которые могут использоваться для коммуникаций через Internet.

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

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

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6)”, RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

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

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

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

[IEEE-P802.1CQ-Project] IEEE, “P802.1CQ – Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment”, <https://standards.ieee.org/project/802_1CQ.html>.

[IEEEStd802] IEEE, “IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, IEEE Std 802”, IEEE STD 802-2014, DOI 10.1109/IEEESTD.2014.6847097, <https://doi.org/10.1109/IEEESTD.2014.6847097>.

[IEEEStd802.11] IEEE, “IEEE Standard for Information technology–Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements – Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”, IEEE Std 802.11, DOI 10.1109/IEEESTD.2016.7786995, <https://doi.org/10.1109/IEEESTD.2016.7786995>.

[IEEEStd802c] IEEE, “IEEE Standard for Local and Metropolitan Area Networks:Overview and Architecture–Amendment 2: Local Medium Access Control (MAC) Address Usage”, IEEE Std 802c-2017, DOI 10.1109/IEEESTD.2017.8016709, <https://doi.org/10.1109/IEEESTD.2017.8016709>.

[RFC2464] Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks”, RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.

[RFC4429] Moore, N., “Optimistic Duplicate Address Detection (DAD) for IPv6”, RFC 4429, DOI 10.17487/RFC4429, April 2006, <https://www.rfc-editor.org/info/rfc4429>.

[RFC5494] Arkko, J. and C. Pignataro, “IANA Allocation Guidelines for the Address Resolution Protocol (ARP)”, RFC 5494, DOI 10.17487/RFC5494, April 2009, <https://www.rfc-editor.org/info/rfc5494>.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, “Guidelines for Creating New DHCPv6 Options”, BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, “Terminology for Constrained-Node Networks”, RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, “Anonymity Profiles for DHCP Clients”, RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8948] Bernardos, CJ. and A. Mourad, “Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6”, RFC 8948, DOI 10.17487/RFC8948, December 2020, <https://www.rfc-editor.org/info/rfc8948>.

Приложение A. IEEE 802c

В этом приложении дана краткая сводка IEEE 802c [IEEEStd802c].

Исходная спецификация IEEE 802 выделяет половину 48-битового пространства MAC-адресов для локального использования. Эти адреса имеют установленный бит U/L (1) и администрируются локально без задания структуры.

В 2017 г. была выпущена спецификация IEEE Std 802c с определением необязательного плана структурированной локальной адресации (Structured Local Address Plan или SLAP), который задает разные подходы к четырем указанным областям пространства локальных адресов MAC. В соответствии с этим планом для 4 квадрантов SLAP заданы разные правила назначения адресов.

В первом (младшем) октете MAC-адреса биты Z и Y определяют квадрант для назначаемых локально адресов (бит X имеет значение 1). Представление IEEE для этих битов показано на рисунке 3

LSB                MSB
M  X  Y  Z  -  -  -  -
|  |  |  |
|  |  |  +------------ SLAP бит Z
|  |  +--------------- SLAP бит Y
|  +------------------ бит X (U/L) = 1 для локальных адресов
+--------------------- бит M (I/G) (unicast/group)

Рисунок 3. Биты SLAP.


Квадранты SLAP описаны в таблице 1.

Таблица 1. Квадранты SLAP.

Квадрант

Бит Y

Бит Z

Тип локального идентификатора

Локальный идентификатор

01

0

1

Расширенный локальный идентификатор

ELI

11

1

1

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

SAI

00

0

0

Административное назначение

AAI

10

1

0

Резерв

Резерв

MAC-адреса из квадранта расширенных локальных идентификаторов (Extended Local Identifier – ELI) основаны на идентификаторе компании (CID) размером 24 бита (включая M, X, Y, Z) для 48-битовых MAC-адресов. Это оставляет 24 бита для локального назначения с каждым идентификатором CID для индивидуальных (M = 0) и групповых (M = 1) адресов. Значения CID распределяются IEEE Registration Authority (RA).

MAC-адреса из квадранта стандартных идентификаторов (Standard Assigned Identifier – SAI) назначаются протоколом, заданным в стандарте IEEE 802. Для 48-битовых адресов MAC доступны 44 бита. Для назначения SAI в стандартах IEEE может быть задано множество протоколов. Сосуществование разных протоколов может поддерживаться за счет ограничения субпространства, доступного каждому протоколу.

MAC-адреса из квадранта административно выделяемых идентификаторов (Administratively Assigned Identifier – AAI) назначаются локально. Администраторы поддерживают пространство адресов по своему разумению. Отметим, что групповые пакеты IPv6 [RFC2464] используют адрес получателя, начинающийся с 33-33, поэтому адреса AAI не следует выделять из этого диапазона. Для 48-битовых MAC-адресов доступны 44 бита.

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

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

Спасибо члена рабочей группы DHC за рецензирование документа, комментарии и поддержку. Отдельная благодарность Ian Farrer за внимательное рецензирование и помощь при прохождении процесса IETF. Спасибо также рецензентам от директората Samita Chakrabarti, Roni Even, Tianran Zhou и членам IESG Martin Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry Leiba, Alvaro Retana, Éric Vyncke, Robert Wilton за их предложения. Спасибо Roger Marks, Robert Grow, Antonio de la Oliva за комментарии, относящиеся к работе IEEE, и ссылки.

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

Bernie Volz

Cisco Systems, Inc.

300 Beaver Brook Rd

Boxborough, MA 01719

United States of America

Email: volz@cisco.com

Tomek Mrugalski

Internet Systems Consortium, Inc.

PO Box 360

Newmarket, NH 03857

United States of America

Email: tomasz.mrugalski@gmail.com

Carlos J. Bernardos

Universidad Carlos III de Madrid

Av. Universidad, 30

28911 Leganes, Madrid

Spain

Phone: +34 91624 6236

Email: cjbc@it.uc3m.es

URI: http://www.it.uc3m.es/cjbc/

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

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

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Organizationally Unique Identifier – уникальный идентификатор организации.

4Media Access Control – управление доступом к среде.

5Universal/Local – универсальный или локальный адрес.

6Идентификационная ассоциация для адресов канального уровня.

Рубрика: RFC | Комментарии к записи RFC 8947 Link-Layer Address Assignment Mechanism for DHCPv6 отключены

RFC 8961 Requirements for Time-Based Loss Detection

image_print
Internet Engineering Task Force (IETF)                         M. Allman
Request for Comments: 8961                                          ICSI
BCP: 233                                                   November 2020
Category: Best Current Practice                                         
ISSN: 2070-1721

Requirements for Time-Based Loss Detection

Требования к детектированию потерь по времени

PDF

Аннотация

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

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

Документ относится к категории Internet Best Current Practice.

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

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

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

Авторские права (Copyright (c) 2020) принадлежат 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 включает множество разных каналов и систем, которые поддерживают широкий класс задач. Предоставляемые через сеть услуги варьируются по качеству от доступного (best-effort) для множества слабо связанных элементов до надежно предсказуемого в контролируемых средах (например, между физически соединенными узлами или в строго контролируемом ЦОДе). У каждого пути через сеть имеется набор параметров, например, доступная пропускная способность, задержка и потеря пакетов. Учитывая разнородность сетей в Internet, можно считать эти свойства варьирующимися от статических до быстро меняющихся.

В этом документе рассматривается одно из свойств пути – потеря пакетов. В частности, предложены рекомендации по разработке и реализации детекторов потерь на основе времени, которые были выработаны за прошедшие десятки лет. Рассматривается достаточно общий случай, когда свойства потери пакетов в пути (a) не известны заранее и (b) меняются с течением времени. Кроме того, несмотря на возможность различных причин потери пакетов, здесь принят консервативный подход о том, что потери являются неявным признаком перегрузки [RFC5681]. Хотя эта позиция верна не во всех случаях, она хорошо послужила в качестве базового допущения, использованного еще в [Jac88]. Как будет отмечено в разделе 2, рекомендации этого документа следует считать базовыми для индивидуального трафика в сетях с доставкой по возможности (best-effort) и неоптимальными, хотя и применимыми в других ситуациях.

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

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

Для обнаружения потерь в потоке пакетов применяются разные механизмы. Часто для этого служат постоянные или периодические подтверждения от получателя для информирования отправителя об отсутствии пакетов. Однако, несмотря на добрые намерения и отказоустойчивые механизмы, невозможно полностью доверять таким подтверждениям, поскольку они могут зависеть от времени и реальным подтверждением потери может являться лишь тайм-аут. То есть отправитель задает те или иные ожидания в части времени подтверждения доставки той или иной порции данных. Когда это время проходит без доставки подтверждения, отправитель считает данные потерянными.

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

  • ждать достаточно долго для корректного детектирования;
  • сократить задержку для приложений (перед повтором) и сети (перед снижением нагрузки).

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

Многие протоколы и приложения, такие как TCP [RFC6298], SCTP [RFC4960] и SIP [RFC3261], включают механизмы обнаружения потерь на основе времени. Опыт использования этих механизмов показывает, что зачастую конкретные настройки, отклоняющиеся от стандартизованных детекторов на основе времени, не оказывают нужного влияния на безопасность сети в части контроля перегрузок [AP99]. Поэтому в данном документе представлен набор независимых от протоколов требований высокого уровня к детектирования потерь на основе времени. Цель документа заключается в создании надежной основы для реализаций, обеспечивающих гибкие механизмы решения конкретной задачи.

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

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

2. Контекст

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

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

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

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

  • Требования документа применимы не во всех случаях, поэтому в будущем могут потребоваться варианты и отклонения (поэтому применен термин следует). Однако несовместимости должны быть (a) объяснены и (b) получить согласие сообщества.

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

Описанные в документе принципы не зависят от протокола и широко применимы. Ниже представлены заявления о применимости требований, приведенных в разделе 4.

  1. Хотя в протоколах применяется множество таймеров (от контроля скорости до обнаружения отказов в соединениях и т. п.), здесь рассматривается лишь обнаружение потерь.

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

    Хотя для таких простых протоколов, как DNS [RFC1034] [RFC1035], достаточно простого детектора потерь, более сложные протоколы часто применяют более совершенные механизмы обнаружения потерь для повышения производительности. Например, в TCP и SCTP имеются методы обнаружения (и восстановления) потерь на основе явного обобщения состояния конечной точки [RFC2018] [RFC4960] [RFC6675]. Такие механизмы часто обеспечивают более своевременное и точное обнаружение потерь, нежели детекторы на основе времени. Однако эти механизмы не избавляют от необходимости поддерживать тайм-аут повтора (retransmission timeout) или RTO, как отмечено в разделе 1, и в конечном счете могут полагаться лишь на прохождение времени для детектирования потери. Иными словами, нет возможности рассчитывать на прибытие подтверждения отправителю данных как на указание пакетов, которые не пришли к получателю. В таких случаях все равно нужен детектор на основе времени, который сработает в крайнем случае.

    Отметим также, что некоторые недавние предложения включают время как часть метода обнаружения потерь в качестве агрессивного детектирования первой потери в некоторых ситуациях или вместе с обобществлением состояний конечных точек [DCCM13] [CCDJ20] [IS20]. Хотя эти механизмы могут способствовать своевременному восстановлению, протокол в конечном итоге опирается на более консервативный таймер для обеспечения надежности при выходе этих механизмов из строя. Требования этого документа напрямую применимы лишь к крайнему варианту обнаружения потерь (last-resort). Однако предполагается, что многие из требований послужат полезным руководством для менее агрессивных таймеров, не предназначенных для крайних случаев.

  3. Требования этого документа относятся лишь к взаимодействию между парами конечных точек по индивидуальным (unicast) адресам. Протоколы группового взаимодействия (например, [RFC5740]) явно выходят за рамки документа.Такие протоколы, как SCTP [RFC4960] и Multipath TCP (MP-TCP) [RFC6182], использующие unicast-адресацию для множества конечных точек, могут применять требования документа при условии отслеживания состояний и независимого выполнения требований каждой точкой. Т.е. при взаимодействии хоста A с хостами B и C хост A должен применять независимое детектирование потерь на основе времени для трафика, передаваемого B и C.
  4. В некоторых случаях общее состояние используется несколькими соединениями или потоками (например, [RFC2140] и [RFC3124]). Состояние, относящееся к обнаружению потерь по времени, часто считается доступным для совместного использования. Такие ситуации вызывают вопросы, которые простой механизм обнаружения связанных с потоком потерь по времени, рассматриваемый здесь, не решает (например, продолжительность сохранения состояний между соединениями). Поэтому совместное использование потоками общей информации о потерях на основе времени выходит за рамки документа, хотя к нему и применимы общие принципы раздела 4.

4. Требования

Здесь приведены требования, применимые при разработке основных (primary) или крайних (last-resort) механизмов обнаружения потерь на основе времени. По историческим причинам и для простоты описания время между отправкой пакета и фиксацией его потери по отсутствию подтверждения называется тайм-аутом повтора (retransmission timeout или RTO). По истечении RTO без подтверждения доставки отправитель может в суверенностью считать пакет потерянным. Однако, как было отмечено выше, обнаруженную потерю не требуется восстанавливать (т. е. потеря принимается для контроля перегрузок, но не для обеспечения гарантий доставки).

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

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

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

Конкретная константа (1 сеунда) получена из анализа времени кругового обхода в Internet (RTT), приведенного в Приложении A [RFC6298].

  1. Здесь заданы 4 требования, относящиеся к установке ожидаемого интервала подтверждения доставки.

    Часто измерение времени, требуемого для подтверждения доставки, воспринимается как определение RTT для сетевого пути. RTT – это минимальное время, которое требуется для подтверждения доставки, которое часто зависит от поведения протокола в части скорости генерации подтверждения при доставке. Например, это относится к RTO, используемому в TCP [RFC6298] и SCTP [RFC4960]. Однако это иной раз вводит в заблуждение и ожидаемую задержку лучше означит как время обратной связи (feedback time или FT). Иными словами, ожидаемое время не всегда отражает свойства сети и может включать дополнительную задержку, которую следует учитывать отправителю.

    Рассмотрим, например, UDP-запрос DNS от клиента к рекурсивному распознавателю [RFC1035]. При обслуживании запроса из кэша распознавателя, время обратной связи (FT) будет близко к RTT между клиентом и распознавателем. Однако при отсутствии записи в кэше распознаватель будет запрашивать нужную информацию у одного или нескольких полномочных серверов DNS, что приведет к тредно оцениваемому росту FT по сравнению с RTT между клиентом и распознавателем.

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

    1. Для установки RTO следует использовать несколько наблюдений FT, если они доступны.

      Иными словами, значение RTO должно представлять эмпирически доступное разумное время, в течение отправителю следует ждать подтверждения доставки, прежде чем принимать решение о потере данных. Пути в сети по природе динамичны, поэтому важно учитывать в RTO несколько недавних измерений FT.

      Например, TCP RTO [RFC6298] удовлетворяет этим требованиям благодаря использованию экспоненциально взвешенного скользящего среднего значения (EWMA3) для объединения множества измерений FT в «сглаженное время RTT». Во имя консервативности TCP идет дальше, включая явный учет дисперсии при расчете RTO.

      Несмотря на то, что использование нескольких измерений FT очень важно для учета динамики задержки в пути, здесь явно не задается число и срок действия таких измерений для расчета RTO, поскольку это может зависеть от ситуации и задач конкретного детектора потерь.

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

    2. Измерение FT следует выполнять и включать в RTO не менее 1 раза за период RTT или с частотой обмена пакетами, если пакеты передаются с интервалами больше RTT.

      Измерения в Internet показывают, что однократное измерение FT для соединения TCP приводит к достаточно плохой работе механизма RTO [AP99], поэтому введено требование многократного измерения FT в течение всего времени связи.

      Например, TCP может оценивать FT 1 раз в интервале RTT или для каждого приема подтверждения с временной меткой [RFC7323]. В [AP99] показано, что оба варианта дают близкие оценки RTO.

    3. Оценки FT можно делать не только на основе обмена данными.

      Некоторые протоколы по тем или иным причинам передают не только данные, но и служебные сообщения keepalive, heartbeat, управляющие сообщения. Задержки при таких обменах могут применяться при оценке FT для механизма RTO в той мере, в какой они отражают задержки при обмене данными. Такие измерения могут помочь протоколам сохранить точность RTO при возникновении перерывов в обмене данными. Однако с учетом того, что задержки этих сообщений могут отличаться от задержки при передаче данных, они могут быть полезны не всегда.

    4. Механизму RTO недопустимо применять неоднозначные измерения FT.

      Предположим, что были переданы две копии пакета X в моменты t0 и t1, затем в момент t2 отправитель получил подтверждение доставки X. В некоторых случаях невозможно узнать, какая из копий X вызвала подтверждение, поэтому значением FT может быть как t2-t1, так и t2-t0. В такой ситуации реализации недопустимо использовать любое из этих значений FT для обновления RTO ([KP87] и [RFC6298]).

      В некоторых случаях при отправке двух копий данных можно различить, какую из них подтверждает принятое сообщение ACK. Например, временные метки TCP [RFC7323] позволяют точно установить подтвержденный пакет. Неоднозначности не возникает и измерение пригодно для обновления RTO.

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

    Исключением являются случаи, когда стандартизованный IETF механизм определяет, что данная потеря не связана с перегрузкой (например, повреждение пакета), поэтому контроль перегрузки включать не нужно. Кроме того, действия по контролю перегрузки на основе детектирования потерь по времени могут быть отменены, когда стандартный механизм постфактум определяет, что потеря не связана с перегрузкой (например, [RFC5682]).

  3. При каждом использовании RTO для обнаружения потери значение RTO должно экспоненциально увеличиваться, чтобы следующее срабатывание происходило через более долгий интервал. Изменение тайм-аута следует отменять, если (a) последующая передача произошла без потерь или (b) в течение RTO не было обнаружено дополнительных потерь. Первый вариант обычно наступает быстрее, а второй относится к случаям, когда потеря обнаружена но не устранена. Это обеспечивает защиту сети.

    Для RTO можно задать максимальное значение, которое недопустимо делать меньше 60 секунд, как указано в [RFC6298].

    Как и в случае (3), имеется исключение, если стандартизованный IETF механизм определяет, что потеря не связана с перегрузкой.

5. Обсуждение

Отметим, что исследования показали фундаментальность противоречия между своевременностью и точностью при обнаружении проблем по времени в контексте TCP [AP99]. Т. е. более энергичное применение RTO (например, изменение прироста EWMA, снижение минимального RTO и т. п.) может ускорить обнаружение действительной потери. Однако при этом будет больше ошибочных срабатываний, когда отмеченные потери не будут таковыми на деле. Поэтому максимальная энергичность, разрешаемая приведенными выше требованиями не будет лучшим решением, ведь детектирование потерь (даже ложное) требует реакции на перегрузку, снижающей в итоге скорость передачи.

Хотя противоречие между точностью и своевременностью детектирования является фундаментальным, его важность можно снизить, если отправитель может обнаружить и скомпенсировать ложные срабатывания детектора потерь. Для этого было предложено несколько механизмов, таких как Eifel [RFC3522], F-RTO4 [RFC5682], DSACK5 [RFC2883] [RFC3708]. Применение таких механизмов позволяет отправителю данных реагировать быстрее, но без сопутствующих издержек, связанных с ошибочным детектированием потерь.

Следует также отметить, что в дополнение к экспериментам, описанным в [AP99], реализация Linux TCP много лет использует различные нестандартные механизмы RTO без каких-либо серьезных проблем (например, использование коэффициентов усиления EWMA, отличных от [RFC6298]). Кроме того, во многих реализациях TCP используется минимальное значение RTO в установившемся состоянии, которое меньше 1 секунды, заданной в [RFC6298]. Хотя эти отклонения от стандартов могут приводить к росту числа ложных обнаружений потерь (согласно [AP99]), неизвестно о каких-либо значимых проблемах с безопасностью сетей, вызванных изменением минимального значения RTO. Это учтено в последней рекомендации раздела 4, где не задано минимальное значение RTO.

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

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

Этот документ не меняет свойств безопасности основанных на времени механизмов обнаружения потерь. Рассмотрение этого вопроса в контексте TCP приведено в [RFC6298].

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

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

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

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

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

[AP99] Allman, M. and V. Paxson, “On Estimating End-to-End Network Path Properties”, Proceedings of the ACM SIGCOMM Technical Symposium, September 1999.

[CCDJ20] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, “The RACK-TLP loss detection algorithm for TCP”, Work in Progress, Internet-Draft, draft-ietf-tcpm-rack-13, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-tcpm-rack-13>.

[DCCM13] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, “Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses”, Work in Progress, Internet-Draft, draft-dukkipati-tcpm-tcp-loss-probe-01, 25 February 2013, <https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01>.

[IS20] Iyengar, J., Ed. and I. Swett, Ed., “QUIC Loss Detection and Congestion Control”, Work in Progress, Internet-Draft, draft-ietf-quic-recovery-32, 20 October 2020, <https://tools.ietf.org/html/draft-ietf-quic-recovery-32>.

[Jac88] Jacobson, V., “Congestion avoidance and control”, ACM SIGCOMM, DOI 10.1145/52325.52356, August 1988, <https://doi.org/10.1145/52325.52356>.

[KP87] Karn, P. and C. Partridge, “Improving Round-Trip Time Estimates in Reliable Transport Protocols”, SIGCOMM 87.

[RFC1034] Mockapetris, P., “Domain names – concepts and facilities”, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

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

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, “TCP Selective Acknowledgment Options”, RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.

[RFC2140] Touch, J., “TCP Control Block Interdependence”, RFC 2140, DOI 10.17487/RFC2140, April 1997, <https://www.rfc-editor.org/info/rfc2140>.

[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, “An Extension to the Selective Acknowledgement (SACK) Option for TCP”, RFC 2883, DOI 10.17487/RFC2883, July 2000, <https://www.rfc-editor.org/info/rfc2883>.

[RFC3124] Balakrishnan, H. and S. Seshan, “The Congestion Manager”, RFC 3124, DOI 10.17487/RFC3124, June 2001, <https://www.rfc-editor.org/info/rfc3124>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.

[RFC3522] Ludwig, R. and M. Meyer, “The Eifel Detection Algorithm for TCP”, RFC 3522, DOI 10.17487/RFC3522, April 2003, <https://www.rfc-editor.org/info/rfc3522>.

[RFC3708] Blanton, E. and M. Allman, “Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions”, RFC 3708, DOI 10.17487/RFC3708, February 2004, <https://www.rfc-editor.org/info/rfc3708>.

[RFC4960] Stewart, R., Ed., “Stream Control Transmission Protocol”, RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, “TCP Congestion Control”, RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, “Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP”, RFC 5682, DOI 10.17487/RFC5682, September 2009, <https://www.rfc-editor.org/info/rfc5682>.

[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, “NACK-Oriented Reliable Multicast (NORM) Transport Protocol”, RFC 5740, DOI 10.17487/RFC5740, November 2009, <https://www.rfc-editor.org/info/rfc5740>.

[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, “Architectural Guidelines for Multipath TCP Development”, RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/info/rfc6182>.

[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, “Computing TCP’s Retransmission Timer”, RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.

[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, “A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP”, RFC 6675, DOI 10.17487/RFC6675, August 2012, <https://www.rfc-editor.org/info/rfc6675>.

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

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

Этот документ основан на многолетнем обсуждении с Ethan Blanton, Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, а также с членами рабочих групп TCPM и TCPIMPL. Полезные комментарии к предварительным вариантам документа предоставили Ran Atkinson, Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Wesley Eddy, Gorry Fairhurst, Rahul Arvind Jadhav, Benjamin Kaduk, Mirja Kühlewind, Nicolas Kuhn, Jonathan Looney, Michael Scharf.

Адрес автора

Mark Allman

International Computer Science Institute

2150 Shattuck Ave., Suite 1100

Berkeley, CA 94704

United States of America

Email: mallman@icir.org

URI: https://www.icir.org/mallman

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

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

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Exponentially weighted moving average.

4Forward RTO-Recovery – ускоренное восстановление RTO.

5Duplicate Selective Acknowledgement – селективное подтверждение дубликатов.

Рубрика: RFC | Комментарии к записи RFC 8961 Requirements for Time-Based Loss Detection отключены

RFC 8944 A YANG Data Model for Layer 2 Network Topologies

image_print
Internet Engineering Task Force (IETF)                           J. Dong
Request for Comments: 8944                                        X. Wei
Category: Standards Track                                          Q. Wu
ISSN: 2070-1721                                                   Huawei
                                                            M. Boucadair
                                                                  Orange
                                                                  A. Liu
                                                                  Tecent
                                                           November 2020

A YANG Data Model for Layer 2 Network Topologies

Модель YANG для сетевой топологии канального уровня

PDF

Аннотация

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

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

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

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

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

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

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

[RFC8345] определяет модели данных YANG [RFC6020] [RFC7950] абстрактной (базовой) сети и сетевой топологии, которые можно дополнить зависящими от технологии деталями для построения соответствующей технологии модели.

Этот документ определяет модель данных YANG для сетевых топологий канального уровня (L2) путем дополнения моделей данных базовой сети (параграф 6.1 в [RFC8345]) и базовой топологии (параграф 6.2 в [RFC8345]) относящимися к уровню L2 атрибутами. Пример представлен в приложении B.

Такая модель данных имеет много применений. Например, в контексте интерфейса в систему маршрутизации I2RS3 узлы сети могут использовать модель данных для фиксации своего представления о топологии сети в целом и раскрытия его контроллеру сети. Контроллер может использовать экземпляры данных топологии для сравнения и согласования со своим представлением о топологии сети. В дополнение к этому узлы сети могут сравнивать и согласовывать эти представления между собой самостоятельно или с помощью контроллера. Помимо элементов сети и самого контекста I2RS контроллер сети может применять модель данных для представления контролируемой им топологии внешним приложениям. Другие варианты применения модели данных рассмотрены в [I2RS-UR].

В документе применяются базовые типы YANG, определенные в [RFC6991], и принимается архитектура хранилища NMDA4 [RFC8342].

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

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

Термины для описания модулей YANG определены в [RFC7950], значения символов, используемых в диаграммах деревьев, – в [RFC8340].

3. Модель топологии L2

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

Связь модуля топологии L2 с модулями базовой сети и сетевой топологии показана на рисунке 1. Для представления топологии L2 модели базовой сети и сетевой топологии дополнены относящейся к L2 информацией, такой как идентификаторы, сущности (элементы, например, PBB5 [IEEE802.1ah], QinQ [IEEE802.1ad], VXLAN6 [RFC7348]), атрибуты и состояния сетей L2, узлы, каналы и точки завершения. Часть информации может быть собрана протоколом LLDP7 [IEEE802.1AB] или другим протоколом L2, а другая часть настроена в локальной конфигурации.

+---------------------+
|    ietf-network     |
+----------^----------+
           |
           |
+---------------------+
|ietf-network-topology|
+----------^----------+
           |
           |
+----------^----------+
|   ietf-l2-topology  |
+---------------------+

Рисунок 1. Структура модуля YANG.


Структура модуля YANG ietf-l2-topology в форме дерева представлена ниже.

   module: ietf-l2-topology
     augment /nw:networks/nw:network/nw:network-types:
       +--rw l2-topology!
     augment /nw:networks/nw:network:
       +--rw l2-topology-attributes
          +--rw name?    string
          +--rw flags*   l2-flag-type
     augment /nw:networks/nw:network/nw:node:
       +--rw l2-node-attributes
          +--rw name?                 string
          +--rw flags*                node-flag-type
          +--rw bridge-id*            string
          +--rw management-address*   inet:ip-address
          +--rw management-mac?       yang:mac-address
          +--rw management-vlan?      string
     augment /nw:networks/nw:network/nt:link:
       +--rw l2-link-attributes
          +--rw name?        string
          +--rw flags*       link-flag-type
          +--rw rate?        uint64
          +--rw delay?       uint32
          +--rw auto-nego?   boolean
          +--rw duplex?      duplex-mode
     augment /nw:networks/nw:network/nw:node/nt:termination-point:
       +--rw l2-termination-point-attributes
          +--rw interface-name?       string
          +--rw mac-address?          yang:mac-address
          +--rw port-number*          uint32
          +--rw unnumbered-id*        uint32
          +--rw encapsulation-type?   identityref
          +--rw outer-tag?            dot1q-types:vid-range-type {VLAN}?
          +--rw outer-tpid?           dot1q-types:dot1q-tag-type {QinQ}?
          +--rw inner-tag?            dot1q-types:vid-range-type {VLAN}?
          +--rw inner-tpid?           dot1q-types:dot1q-tag-type {QinQ}?
          +--rw lag?                  boolean
          +--rw member-link-tp*
                 -> /nw:networks/network/node/nt:termination-point/tp-id
          +--rw vxlan {VXLAN}?
             +--rw vni-id?   vni

     notifications:
       +---n l2-node-event
       |  +--ro event-type?           l2-network-event-type
       |  +--ro node-ref?
                         -> /nw:networks/network[nw:network-id=current()
                            /../network-ref]/node/node-id
       |  +--ro network-ref?          -> /nw:networks/network/network-id
       |  +--ro l2-topology!
       |  +--ro l2-node-attributes
       |     +--ro name?                 string
       |     +--ro flags*                node-flag-type
       |     +--ro bridge-id*            uint64
       |     +--ro management-address*   inet:ip-address
       |     +--ro management-mac?       yang:mac-address
       |     +--ro management-vlan?      string
       +---n l2-link-event
       |  +--ro event-type?           l2-network-event-type
       |  +--ro link-ref?
                         -> /nw:networks/network[nw:network-id=current()
                            /../network-ref]/nt:link/link-id
       |  +--ro network-ref?          -> /nw:networks/network/network-id
       |  +--ro l2-topology!
       |  +--ro l2-link-attributes
       |     +--ro name?        string
       |     +--ro flags*       link-flag-type
       |     +--ro rate?        uint64
       |     +--ro delay?       uint32
       |     +--ro auto-nego?   boolean
       |     +--ro duplex?      duplex-mode
       +---n l2-termination-point-event
          +--ro event-type?                        l2-network-event-type
          +--ro tp-ref?
                         -> /nw:networks/network[nw:network-id=current()
                            /../network-ref]/node[nw:node-id=current()
                            /../node-ref]/nt:termination-point/tp-id
          +--ro node-ref?
                         -> /nw:networks/network[nw:network-id=current()
                            /../network-ref]/node/node-id
          +--ro network-ref?          -> /nw:networks/network/network-id
          +--ro l2-topology!
          +--ro l2-termination-point-attributes
             +--ro interface-name?       string
             +--ro mac-address?          yang:mac-address
             +--ro port-number*          uint32
             +--ro unnumbered-id*        uint32
             +--ro encapsulation-type?   identityref
             +--ro outer-tag?         dot1q-types:vid-range-type {VLAN}?
             +--ro outer-tpid?        dot1q-types:dot1q-tag-type {QinQ}?
             +--ro inner-tag?         dot1q-types:vid-range-type {VLAN}?
             +--ro inner-tpid?        dot1q-types:dot1q-tag-type {QinQ}?
             +--ro lag?               boolean
             +--ro member-link-tp*
                 -> /nw:networks/network/node/nt:termination-point/tp-id
             +--ro vxlan {VXLAN}?
                +--ro vni-id?   vni

Модуль YANG для топологии L2 дополняет модули ietf-network и ietf-network-topology.

  • Вводится новый тип l2-network-type, представляемый контейнером и помещаемый под контейнером network-types модуля ietf-network, определенного в параграфе 6.1 [RFC8345].

  • Введены дополнительные атрибуты сети в группировке l2-network-attributes, дополняющие список network модуля ietf-network. Атрибуты включают имя сети L2 и набор флагов. Каждый тип флагов представлен отдельной сущностью (объектом).

  • Вводятся дополнительные элементы (объекты) данных для узлов L2 путем дополнения списка node базового модуля ietf-network. Новые объекты включают идентификатор узла L2, адрес управления, MAC-адрес управления, VLAN для управления и набор флагов.

  • Вводятся дополнительные элементы (объекты) данных для точек завершения L2 путем дополнения списка termination-point модуля ietf-network-topology, определенного в параграфе 6.2 [RFC8345]. Новые объекты включают имя интерфейса, тип инкапсуляции, индикацию поддержки агрегирования (lag) и атрибуты, связанные с типом точки завершения L2.

  • Каналы в модуле ietf-network-topology дополняются набором параметров L2, позволяющим связать канал с именем, набором атрибутов канала L2 и флагами.

  • В модуле введены необязательные атрибуты L2, связанные с технологией, как свойства L2, поскольку такие атрибуты могут быть полезны для раскрытия вышележащим службам (приложениям). Отметим, что изучение или настройка таких расширенных атрибутов L2 выходят за рамки модуля YANG для топологии L2 и следует использовать для них дополнительные модули YANG (например, [TRILL-YANG]).

4. Модуль YANG для топологии L2

Этот модуль использует типы, определенные в [RFC6991], [RFC7224], [IEEE802.1Qcp] и [RFC8345], а также ссылается на [IEEE802.1Q-2014], [IEEE802.1ad], [RFC7348] и [RFC7727].

   <CODE BEGINS> file "ietf-l2-topology@2020-11-15.yang"
   module ietf-l2-topology {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology";
     prefix l2t;

     import ietf-network {
       prefix nw;
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }
     import ietf-network-topology {
       prefix nt;
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991:Common YANG Data Types";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991:Common YANG Data Types";
     }
     import iana-if-type {
       prefix ianaift;
       reference
         "RFC 7224: IANA Interface Type YANG Module";
     }
     import ieee802-dot1q-types {
       prefix dot1q-types;
       reference
         "IEEE Std 802.1Qcp-2018: Bridges and Bridged
          Networks - Amendment: YANG Data Model";
     }

     organization
       "IETF I2RS (Interface to the Routing System) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/i2rs> 
        WG List:  <mailto:i2rs@ietf.org>

        Editor:    Jie Dong
                  <mailto:jie.dong@huawei.com> 

        Editor:    Xiugang Wei
                  <mailto:weixiugang@huawei.com> 

        Editor:    Qin Wu
                  <mailto:bill.wu@huawei.com> 

        Editor:    Mohamed Boucadair
                  <mailto:mohamed.boucadair@orange.com> 

        Editor:    Anders Liu
                  <mailto:andersliu@tencent.com>"; 
     description
       "Этот модуль определяет базовую модель сетевой топологии L2.

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

        Распространение и использование в исходной или двоичной форме
        с изменениями или без таковых разрешено в соответствии с
        упрощенной лицензией BSD, как указано в параграфе 4.c
        документа IETF Trust Legal Provisions применительно к
        документам IETF (https://trustee.ietf.org/license-info).

        Данная версия модуля YANG является частью RFC 8944, где 
        правовые аспекты изложены более полно.";

     revision 2020-11-15 {
       description
         "Исходный выпуск.";
       reference
         "RFC 8944: A YANG Data Model for Layer 2 Network Topologies";
     }

     feature VLAN {
       description
         "Включает поддержку VLAN в соответствии с IEEE 802.1Q.";
       reference
         "IEEE Std 802.1Q-2014: Bridges and Bridged Networks";
     }

     feature QinQ {
       description
         "Включает поддержку двойных тегов QinQ IEEE 802.1ad.";
       reference
         "IEEE Std 802.1ad: Provider Bridges";
     }

     feature VXLAN {
       description
         "Включает поддержку VXLAN в соответствии с RFC 7348.";
       reference
         "RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
                    A Framework for Overlaying Virtualized Layer 2
                    Networks over Layer 3 Networks";
     }

     identity flag-identity {
       description
         "базовый тип для флагов.";
     }

     identity eth-encapsulation-type {
       base ianaift:iana-interface-type;
       description
         "Базовое отождествление, из которого выводятся конкретные
          типы инкапсуляции Ethernet.";
       reference
         "RFC 7224: IANA Interface Type YANG Module";
     }

     identity ethernet {
       base eth-encapsulation-type;
       description
         "Естественная инкапсуляция Ethernet.";
     }

     identity vlan {
       base eth-encapsulation-type;
       description
         "Инкапсуляция VLAN.";
     }

     identity qinq {
       base eth-encapsulation-type;
       description
         "Инкапсуляция QinQ.";
     }

     identity pbb {
       base eth-encapsulation-type;
       description
         "Инкапсуляция PBB в соответствии с IEEE 802.1ah.";
     }

     identity trill {
       base eth-encapsulation-type;
       description
         "Инкапсуляция TRILL.";
     }

     identity vpls {
       base eth-encapsulation-type;
       description
         "Инкапсуляция интерфейса VPLS.";
     }

     identity vxlan {
       base eth-encapsulation-type;
       description
         "Инкапсуляция VXLAN MAC в UDP.";
       reference
         "RFC 7348: Virtual eXtensible Local Area  Network (VXLAN):
                    A Framework for Overlaying Virtualized Layer 2
                    Networks over Layer 3 Networks";
     }

     typedef vni {
       type uint32 {
         range "0..16777215";
       }
       description
         "Идентификатор сети или сегмента VXLAN, обеспечивающий
          сосуществование до 16M сегментов VXLAN в одном
          административном домене.

          Использование значения 0 зависит от реализации.";
       reference
         "RFC 7348: Virtual eXtensible Local Area  Network (VXLAN):
                    A Framework for Overlaying Virtualized Layer 2
                    Networks over Layer 3 Networks";
     }

     typedef l2-flag-type {
       type identityref {
         base flag-identity;
       }
       description
         "Базовый тип для флагов L2. Примером типа флага L2 
          является trill, представляющий топологию типа trill.";
     }

     typedef node-flag-type {
       type identityref {
         base flag-identity;
       }
       description
         "Атрибуты флага узла. Примером может служить 
          физический узел.";
     }

     typedef link-flag-type {
       type identityref {
         base flag-identity;
       }
       description
         "Атрибуты флага соединения. Одним из примеров служит
          псевдопровод.";
     }

     typedef l2-network-event-type {
       type enumeration {
         enum addition {
           value 0;
           description
             "Добавлен узел, канал или точка завершения L2.";
         }
         enum removal {
           value 1;
           description
             "Удален узел, канал или точка завершения L2.";
         }
         enum update {
           value 2;
           description
             "Изменен узел, канал или точка завершения L2.";
         }
       }
       description
         "Тип события сети L2 для уведомления.";
     }

     typedef duplex-mode {
       type enumeration {
         enum full-duplex {
           description
             "Указывает полнодуплексный режим.";
         }
         enum half-duplex {
           description
             "Указывает полудуплексный режим.";
         }
       }
       description
         "Указывает тип дуплексного режима.";
     }

     grouping l2-network-type {
       description
         "Указывает, что топология относится к типу L2.";
       container l2-topology {
         presence "Indicates L2 Network Topology.";
         description
           "Наличие контейнерного узла указывает сетевую
            топологию L2.";
       }
     }

     grouping l2-topology-attributes {
       description
         "Атрибуты области действия топологии L2.";
       container l2-topology-attributes {
         description
           "Содержит атрибуты топологии L2.";
         leaf name {
           type string;
           description
             "Имя топологии.";
         }
         leaf-list flags {
           type l2-flag-type;
           description
             "Флаги топологии.";
         }
       }
     }

     grouping l2-node-attributes {
       description
         "Атрибуты узла L2.";
       container l2-node-attributes {
         description
           "Содержит атрибуты узла L2 .";
         leaf name {
           type string;
           description
             "Имя узла.";
         }
         leaf-list flags {
           type node-flag-type;
           description
             "Флаги узла. Могут служить для указания 
              атрибутов флага узла.";
         }
         leaf-list bridge-id {
           type string {
             pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){7}';
           }
           description
             "Идентификатор моста в форме строки октетов 
              из 8 шестнадцатеричных чисел. Включает 4 бита
              приоритета, 12-битовый идентификатор MSTI-ID и
              базовый идентификатор моста. Идентификаторы
              могут присутствовать для каждого экземпляра STP.";
           reference
             "RFC 7727: Spanning Tree Protocol (STP) Application of
                        the Inter-Chassis Communication Protocol
                        (ICCP)";
         }
         leaf-list management-address {
           type inet:ip-address;
           description
             "IP-адрес для управления.";
         }
         leaf management-mac {
           type yang:mac-address;
           description
             "MAC-адрес для управления мостом. Это может быть
              Bridge Base VLAN ID (VID), MAC-адрес интерфейса и пр.";
         }
         leaf management-vlan {
           type string;
           description
             "VLAN, поддерживающая адрес управления. Тип и значение
              реального VLAN ID будут относится к этой VLAN.";
         }
       }
     }

     grouping l2-link-attributes {
       description
         "L2 link attributes.";
       container l2-link-attributes {
         description
           "Содержит атрибуты соединения L2.";
         leaf name {
           type string;
           description
             "Link name.";
         }
         leaf-list flags {
           type link-flag-type;
           description
             "Флаги соединения. Может применяться для
              флагов атрибута соединения.";
         }
         leaf rate {
           type uint64;
           units "Kbps";
           description
             "Скорость соединения. Задает требования к 
              пропускной способности для конкретного 
              соединения между источником и получателем.";
         }
         leaf delay {
           type uint32;
           units "microseconds";
           description
             "Односторонняя задержка в микросекундах.";
         }
         leaf auto-nego {
           type boolean;
           default "true";
           description
             "Значение true при поддержке автосогласования,
              false, если автосогласование не поддерживается.";
         }
         leaf duplex {
           type duplex-mode;
           description
             "Раскрывает режим дуплека - full-duplex или half-duplex.";
         }
       }
     }

     grouping l2-termination-point-attributes {
       description
         "Атрибуты точки завершения L2.";
       container l2-termination-point-attributes {
         description
           "Содержит атрибуты точки завершения L2 .";
         leaf interface-name {
           type string;
           description
             "Имя интерфейса, которое может (но не обязано) 
              соответствовать ссылке на интерфейс содержащего узла,
              т. е. имя пути к узлу данных соответствующего 
              интерфейса на содержащем узле напоминает тип
              данных interface-ref, определенный в RFC 8343.
              Следует отметить, что тип interface-ref из RFC 8343
              нельзя использовать напрямую, поскольку он служит для
              ссылки на интерфейс в хранилище данных одного узла сети,
              а не однозначного указания интерфейсов в сети.";
         }
         leaf mac-address {
           type yang:mac-address;
           description
             "MAC-адрес интерфейса для управления логическим каналом.";
         }
         leaf-list port-number {
           type uint32;
           description
             "Список номеров портов моста, для которых каждая запись
              содержит информацию управления.";
         }
         leaf-list unnumbered-id {
           type uint32;
           description
             "Список идентификаторов безадресных интерфейсов.
              Такой идентификатор будет соответствовать значению
              ifIndex для интерфейса, т. е. значению ifIndex для
              ifEntry, представляющей интерфейс в реализации, где
              поддерживается Interfaces Group MIB (RFC 2863).";
         }
         leaf encapsulation-type {
           type identityref {
             base eth-encapsulation-type;
           }
           description
             "Тип инкапсуляции для этой точки завершения.";
         }
         leaf outer-tag {
           if-feature "VLAN";
           type dot1q-types:vid-range-type;
           description
             "Внешний тег VLAN. Может указываться список VLAN
              или не перекрывающиеся диапазоны VLAN.";
         }
         leaf outer-tpid {
           if-feature "QinQ";
           type dot1q-types:dot1q-tag-type;
           description
             "Указывает конкретный тип 802.1Q внешнего тега VLAN.";
         }
         leaf inner-tag {
           if-feature "VLAN";
           type dot1q-types:vid-range-type;
           description
             "Внутренний тег VLAN. Может указываться список VLAN
              или не перекрывающиеся диапазоны VLAN";
         }
         leaf inner-tpid {
           if-feature "QinQ";
           type dot1q-types:dot1q-tag-type;
           description
             "Указывает конкретный тип 802.1Q внутреннего тега VLAN .";
         }
         leaf lag {
           type boolean;
           default "false";
           description
             "Указывает поддерживается ли агрегирование (lag).
              Значение true говорит о наличии поддержки.";
         }
         leaf-list member-link-tp {
           when "../lag = 'true'" {
             description
               "Используется только при поддержке интерфейсов lag.";
           }
           type leafref {
             path "/nw:networks/nw:network/nw:node"
                + "/nt:termination-point/nt:tp-id";
           }
           description
             "Список точек завершения каналов, связанных с конкретной
              точкой завершения L2.";
         }
         container vxlan {
           when "derived-from-or-self(../encapsulation-type, "
              + "'l2t:vxlan')" {
             description
               "Применимо лишь при инкапсуляции Ethernet типа vxlan.";
           }
           if-feature "VXLAN";
           leaf vni-id {
             type vni;
             description
               "VXLAN Network Identifier (VNI).";
           }
           description
             "Тип инкапсуляции VXLAN.";
         }
       }
     }

     augment "/nw:networks/nw:network/nw:network-types" {
       description
         "Вводит новый тип сети для топологии L2.";
       uses l2-network-type;
     }
     augment "/nw:networks/nw:network" {
       when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
         description
           "Параметры дополнения, применимые лишь к сети с топологией L2.";
       }
       description
         "Конфигурационные параметры для сети L2 в целом.";
       uses l2-topology-attributes;
     }
     augment "/nw:networks/nw:network/nw:node" {
       when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
         description
           "Параметры дополнения, применимые лишь к сети с топологией L2.";
       }
       description
         "Конфигурационные параметры для L2 на уровне узла.";
       uses l2-node-attributes;
     }
     augment "/nw:networks/nw:network/nt:link" {
       when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
         description
           "Параметры дополнения, применимые лишь к сети с топологией L2.";
       }
       description
         "Дополнение топологической информации канала L2.";
       uses l2-link-attributes;
     }
     augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
       when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
         description
           "Параметры дополнения, применимые лишь к сети с топологией L2.";
       }
       description
         "Дополнение топологических данных точки завершения L2.";
       uses l2-termination-point-attributes;
     }

     notification l2-node-event {
       description
         "Уведомление о событии на узле L2.";
       leaf event-type {
         type l2-network-event-type;
         description
           "Тип события.";
       }
       uses nw:node-ref;
       uses l2-network-type;
       uses l2-node-attributes;
     }

     notification l2-link-event {
       description
         "Уведомление о событии на канале L2.";
       leaf event-type {
         type l2-network-event-type;
         description
           "Тип события.";
       }
       uses nt:link-ref;
       uses l2-network-type;
       uses l2-link-attributes;
     }

     notification l2-termination-point-event {
       description
         "Уведомление о событии в точке завершения L2.";
       leaf event-type {
         type l2-network-event-type;
         description
           "Тип события.";
       }
       uses nt:tp-ref;
       uses l2-network-type;
       uses l2-termination-point-attributes;
     }
   }
   <CODE ENDS>

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

Агентство IANA зарегистрировало приведенные ниже URI в субреестре ns реестра The IETF XML Registry [RFC3688]:

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

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

   IANA has registered the following YANG modules in the "YANG Module
   Names" subregistry [RFC6020] within the "YANG Parameters" registry.

   Name:  ietf-l2-topology
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-l2-topology
   Prefix:  l2t
   Reference:  RFC 8944

   Name:  ietf-l2-topology-state
   Namespace:  urn:ietf:params:xml:ns:yang:ietf-l2-topology-state
   Prefix:  l2t-s
   Reference:  RFC 8944

Эти модули не поддерживаются IANA.

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

Заданные этим документом модули YANG определяют схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF8 [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищенный транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446]. Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определенных пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.

Модуль топологии L2 задает данные, которые могут быть настраиваемыми в некоторых экземплярах (например, для виртуальной топологии, создаваемой клиентским приложением). В таких случаях вредоносный клиент может создавать нежелательную топологию. В частности, он может пытаться удалить или добавить узлы, каналы или точки завершения, создавая или удаляя соответствующие элементы в списках узлов, каналов или точек завершения. При изучении топологии сервер будет автоматически запрещать такие попытки недопустимой настройки. Для настроенной топологии (из хранилища intended) нежелательная конфигурация может вступить в силу и попасть в хранилище рабочей конфигурации [RFC8342], приводя к нарушению работы служб, обеспечиваемых через такую топологию. Поэтому важно применять NACM для предотвращения изменения топологии не имеющими полномочий клиентами.

В этом модуле данных YANG определено множество узлов данных, которые разрешают запись, создание и удаление (т. е. По умолчанию config имеет значение true). Эти узлы могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Запись в такие узлы (например, edit-config) без должной защиты может негативно влиять на работу сети. Ниже перечислены субдеревья и узлы, которые могут быть конфиденциальны или уязвимы.

l2-network-attributes

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

l2-node-attributes

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

l2-link-attributes

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

l2-termination-point-attributes:

Враждебный клиент может пытаться сорвать настройку важных атрибутов точки завершения (например, maximum-frame-size).

Некоторые из доступных для чтения узлов в этом модуле YANG могут быть конфиденциальны или уязвимы в той или иной сетевой среде. Важно контролировать доступ к таким объектам (например, get, get-config, notification). В частности, модуль YANG для топологии L2 может раскрывать конфиденциальную информацию, например, MAC-адреса устройств или идентификаторы VLAN илиVXLAN. Неограниченный доступ к такой информации может приводить к нарушению конфиденциальности. Из MAC-адресов сетевых устройств можно получить информацию об их размещении для обхода защиты таких данных в операционной системе.

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

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

[RFC7224] Bjorklund, M., “IANA Interface Type YANG Module”, RFC 7224, DOI 10.17487/RFC7224, May 2014, <https://www.rfc-editor.org/info/rfc7224>.

[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, “Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks”, RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, “A YANG Data Model for Network Topologies”, RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.

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

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

[I2RS-UR] Hares, S. and M. Chen, “Summary of I2RS Use Case Requirements”, Work in Progress, Internet-Draft, draft-ietf-i2rs-usecase-reqs-summary-03, 15 November 2016, <https://tools.ietf.org/html/draft-ietf-i2rs-usecase-reqs-summary-03>.

[IEEE802.1AB] IEEE, “IEEE Standard for Local and metropolitan area networks – Station and Media Access Control Connectivity Discovery”, IEEE Std 802.1AB-2016, DOI 10.1109/IEEESTD.2016.7433915, March 2016, <https://doi.org/10.1109/IEEESTD.2016.7433915>.

[IEEE802.1ad] IEEE, “IEEE Standard for Local and Metropolitan Area Networks–Virtual Bridged Local Area Networks—Amendment 4: Provider Bridges”, IEEE Std 802.1ad-2005, DOI 10.1109/IEEESTD.2006.6044678, May 2006, <https://doi.org/10.1109/IEEESTD.2006.6044678>.

[IEEE802.1ah] IEEE, “IEEE Standard for Local and metropolitan area networks — Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges”, IEEE Std 802.1ah-2008, DOI 10.1109/IEEESTD.2008.4602826, August 2008, <https://doi.org/10.1109/IEEESTD.2008.4602826>.

[IEEE802.1Q-2014] IEEE, “IEEE Standard for Local and metropolitan area networks–Bridges and Bridged Networks”, IEEE 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, December 2014, <https://doi.org/10.1109/IEEESTD.2014.6991462>.

[IEEE802.1Qcp] IEEE, “IEEE Standard for Local and metropolitan area networks–Bridges and Bridged Networks–Amendment 30: YANG Data Model”, IEEE Std 802.1Qcp-2018, DOI 10.1109/IEEESTD.2018.8467507, September 2018, <https://doi.org/10.1109/IEEESTD.2018.8467507>.

[RFC7727] Zhang, M., Wen, H., and J. Hu, “Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)”, RFC 7727, DOI 10.17487/RFC7727, January 2016, <https://www.rfc-editor.org/info/rfc7727>.

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

[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[TRILL-YANG] Hao, W., Li, Y., Kumar, D., Durrani, M., Zhai, H., and L. Xia, “TRILL YANG Data Model”, Work in Progress, Internet-Draft, draft-ietf-trill-yang-04, 20 December 2015, <https://tools.ietf.org/html/draft-ietf-trill-yang-04>.

Приложение A. Модуль для реализаций без поддержки NMDA

Определенный здесь модуль YANG ietf-l2-topology дополняет модули ietf-network и ietf-network-topology, разработанные для использования с реализациями, поддерживающими хранилища NMDA [RFC8342]. Для работы с реализациями, не поддерживающими NMDA, определен набор сопутствующих модулей, представляющих модель состояния сети и топологию, ietf-network-state и ietf-network-topology-state.

Для использования определенной в этом документе модели топологии L2 с реализациями без поддержки NMDA создан сопутствующий модуль, представляющий рабочее состояние топологии L2. Модуль ietf-l2-topology-state соответствует модулю ietf-l2-topology, определенному в разделе 4, однако он дополняет ietf-network-state и ietf-network-topology-state (вместо ietf-network и ietf-network-topology), а все его узлы данных являются ненастраиваемыми.

Модуль ietf-l2-topology не следует поддерживать в реализациях, поддерживающих NMDA. По этой причине модуль определен в информационном приложении.

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

   <CODE BEGINS> file "ietf-l2-topology-state@2020-11-15.yang"
   module ietf-l2-topology-state {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology-state";
     prefix l2t-s;

     import ietf-network-state {
       prefix nw-s;
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }
     import ietf-network-topology-state {
       prefix nt-s;
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }
     import ietf-l2-topology {
       prefix l2t;
       reference
         "RFC 8944: A YANG Data Model for Layer 2 Network Topologies";
     }

     organization
       "IETF I2RS (Interface to the Routing System) Working Group";
     contact
       "WG Web:   <http://tools.ietf.org/wg/i2rs/> 
        WG List:  <mailto:i2rs@ietf.org>

        Editor:    Jie Dong
                  <mailto:jie.dong@huawei.com> 
        Editor:    Xiugang Wei
                  <mailto:weixiugang@huawei.com> 
        Editor:    Qin Wu
                  <mailto:bill.wu@huawei.com> 
        Editor:    Mohamed Boucadair
                  <mailto:mohamed.boucadair@orange.com> 
        Editor:   Anders Liu
                  <andersliu@tencent.com>"; 
     description
       "Этот модуль определяет модель состояния сетевой топологии L2,
        представляя топологию, которая была изучена (learned) или
        является результатом применения модели ietf-l2-topolog,
        отражающей узлы данных этой модели.

        Модель отражает ietf-l2-topology, но включает только данные
        состояния, доступные лишь для чтения ( read-only). Модель не
        нужна при поддержке базовой инфраструктурой хранилища NMDA.

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

        Распространение и использование в исходной или двоичной форме
        с изменениями или без таковых разрешено в соответствии с
        упрощенной лицензией BSD, как указано в параграфе 4.c
        документа IETF Trust Legal Provisions применительно к
        документам IETF (https://trustee.ietf.org/license-info).

        Данная версия модуля YANG является частью RFC 8944, где 
        правовые аспекты изложены более полно.";

     revision 2020-11-15 {
       description
         "Исходный выпуск.";
       reference
         "RFC 8944: A YANG Data Model for Layer 2 Network Topologies";
     }

     /*
      * Узлы данных
      */

     augment "/nw-s:networks/nw-s:network/nw-s:network-types" {
       description
         "Вводит новый тип сети для топологии L2.";
       uses l2t:l2-network-type;
     }

     augment "/nw-s:networks/nw-s:network" {
       when 'nw-s:network-types/l2t-s:l2-topology' {
         description
           "Параметры дополнения для сетей с топологией L2.";
       }
       description
         "Конфигурационные параметры сети L2 в целом.";
       uses l2t:l2-topology-attributes;
     }

     augment "/nw-s:networks/nw-s:network/nw-s:node" {
       when '../nw-s:network-types/l2t-s:l2-topology' {
         description
           "Параметры дополнения для сетей с топологией L2.";
       }
       description
         "Конфигурационные параметры L2 на уровне узла.";
       uses l2t:l2-node-attributes;
     }

     augment "/nw-s:networks/nw-s:network/nt-s:link" {
       when '../nw-s:network-types/l2t-s:l2-topology' {
         description
           "Параметры дополнения для сетей с топологией L2.";
       }
       description
         "Дополнение топологической информации канала L2.";
       uses l2t:l2-link-attributes;
     }

     augment "/nw-s:networks/nw-s:network/nw-s:node/"
           + "nt-s:termination-point" {
       when '../../nw-s:network-types/l2t-s:l2-topology' {
         description
           "Параметры дополнения для сетей с топологией L2.";
       }
       description
         "Дополнение данных топологии точки завершения L2.";
       uses l2t:l2-termination-point-attributes;
     }

     /*
      * Уведомления
      */

     notification l2-node-event {
       description
         "Уведомление о событии на узле L2.";
       leaf event-type {
         type l2t:l2-network-event-type;
         description
           "Event type.";
       }
       uses nw-s:node-ref;
       uses l2t:l2-network-type;
       uses l2t:l2-node-attributes;
     }

     notification l2-link-event {
       description
         "Уведомление о событии на канале L2.";
       leaf event-type {
         type l2t:l2-network-event-type;
         description
           "Event type.";
       }
       uses nt-s:link-ref;
       uses l2t:l2-network-type;
       uses l2t:l2-link-attributes;
     }

     notification l2-termination-point-event {
       description
         "Уведомление о событии в точке завершения L2.";
       leaf event-type {
         type l2t:l2-network-event-type;
         description
           "Event type.";
       }
       uses nt-s:tp-ref;
       uses l2t:l2-network-type;
       uses l2t:l2-termination-point-attributes;
     }
   }
   <CODE ENDS>

Приложение B. Пример

В этом приложении дан пример экземпляра дерева данных в представлении JSON [RFC7951]. Пример создает топологию ietf-l2-topology для показанной на рисунке 2 сети. Здесь имеется три узла – D1, D2, D3. В D1 имеется три точки завершения (1-0-1, 1-2-1, 1-3-1), в D2 тоже три (2-1-1, 2-0-1, 2-3-1), а в D3 – две (3-1-1 и 3-2-1). Точка завершения 1-0-1 поддерживает lag с двумя каналами 1-0-1-1 и 1-0-1-2. Имеется 6 односторонних каналов, по два между каждой парой точек.

            +------------+                   +------------+
            |     D1     |                   |     D2     |
   1-0-1-1 /-\          /-\                 /-\          /-\
<--------->| | 1-0-1    | |---------------->| | 2-1-1    | |
   1-0-1-2 | |    1-2-1 | |<----------------| |    2-0-1 | |
<--------> \-/  1-3-1   \-/                 \-/  2-3-1   \-/
            |   /----\   |                   |   /----\   |
            +---|    |---+                   +---|    |---+
                \----/                           \----/
                 A  |                             A  |
                 |  |                             |  |
                 |  |                             |  |
                 |  |       +------------+        |  |
                 |  |       |     D3     |        |  |
                 |  |      /-\          /-\       |  |
                 |  +----->| | 3-1-1    | |-------+  |
                 +---------| |    3-2-1 | |<---------+
                           \-/          \-/
                            |            |
                            +------------+

Рисунок 2. Пример топологии сети.


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

   {
     "ietf-network:networks": {
       "network": [
         {
           "network-id": "l2-topo-example",
           "node": [
             {
               "node-id": "D1",
               "ietf-network-topology:termination-point": [
                 {
                   "tp-id": "1-0-1",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:d0",
                     "lag": true,
                     "member-link-tp": [
                       "1-0-1-1",
                       "1-0-1-2"
                     ]
                   }
                 },
                 {
                   "tp-id": "1-0-1-1",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:d3"
                   }
                 },
                 {
                   "tp-id": "1-0-1-2",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:d4"
                   }
                 },
                 {
                   "tp-id": "1-2-1",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:d1"
                   }
                 },
                 {
                   "tp-id": "1-3-1",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:d2"
                   }
                 }
               ],
               "ietf-l2-topology:l2-node-attributes": {
                 "management-address": [
                   "192.0.2.1",
                   "2001:db8:0:1::"
                 ]
               }
             },
             {
               "node-id": "D2",
               "ietf-network-topology:termination-point": [
                 {
                   "tp-id": "2-0-1",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:e0"
                   }
                 },
                 {
                   "tp-id": "2-1-1",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:e1"
                   }
                 },
                 {
                   "tp-id": "2-3-1",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:e2"
                   }
                 }
               ],
               "ietf-l2-topology:l2-node-attributes": {
                 "management-address": [
                   "192.0.2.2",
                   "2001:db8:0:2::"
                 ]
               }
             },
             {
               "node-id": "D3",
               "ietf-network-topology:termination-point": [
                 {
                   "tp-id": "3-1-1",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:f0"
                   }
                 },
                 {
                   "tp-id": "3-2-1",
                   "ietf-l2-topology:l2-termination-point-attributes": {
                     "mac-address": "00:00:5e:00:53:f1"
                   }
                 }
               ],
               "ietf-l2-topology:l2-node-attributes": {
                 "management-address": [
                   "192.0.2.3",
                   "2001:db8:0:3::"
                 ]
               }
             }
           ],
           "ietf-network-topology:link": [
             {
               "link-id": "D1,1-2-1,D2,2-1-1",
               "source": {
                 "source-node": "D1",
                 "source-tp": "1-2-1"
               },
               "destination": {
                 "dest-node": "D2",
                 "dest-tp": "2-1-1"
               },
               "ietf-l2-topology:l2-link-attributes": {
                 "rate": "1000"
               }
             },
             {
               "link-id": "D2,2-1-1,D1,1-2-1",
               "source": {
                 "source-node": "D2",
                 "source-tp": "2-1-1"
               },
               "destination": {
                 "dest-node": "D1",
                 "dest-tp": "1-2-1"
               },
               "ietf-l2-topology:l2-link-attributes": {
                 "rate": "1000"
               }
             },
             {
               "link-id": "D1,1-3-1,D3,3-1-1",
               "source": {
                 "source-node": "D1",
                 "source-tp": "1-3-1"
               },
               "destination": {
                 "dest-node": "D3",
                 "dest-tp": "3-1-1"
               },
               "ietf-l2-topology:l2-link-attributes": {
                 "rate": "1000"
               }
             },
             {
               "link-id": "D3,3-1-1,D1,1-3-1",
               "source": {
                 "source-node": "D3",
                 "source-tp": "3-1-1"
               },
               "destination": {
                 "dest-node": "D1",
                 "dest-tp": "1-3-1"
               },
               "ietf-l2-topology:l2-link-attributes": {
                 "rate": "1000"
               }
             },
             {
               "link-id": "D2,2-3-1,D3,3-2-1",
               "source": {
                 "source-node": "D2",
                 "source-tp": "2-3-1"
               },
               "destination": {
                 "dest-node": "D3",
                 "dest-tp": "3-2-1"
               },
               "ietf-l2-topology:l2-link-attributes": {
                 "rate": "1000"
               }
             },
             {
               "link-id": "D3,3-2-1,D2,2-3-1",
               "source": {
                 "source-node": "D3",
                 "source-tp": "3-2-1"
               },
               "destination": {
                 "dest-node": "D2",
                 "dest-tp": "2-3-1"
               },
               "ietf-l2-topology:l2-link-attributes": {
                 "rate": "1000"
               }
             }
           ]
         }
       ]
     }
   }

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

Авторы признательны за комментарии и предложения Susan Hares, Alia Atlas, Juergen Schoenwaelder, Mach Chen, Alexander Clemm, Sriganesh Kini, Oscar Gonzalez de Dios, Stig Venaas, Christian Huitema, Meral Shirazipour, Benjamin Kaduk, Don Fedyk.

Большое спасибо Ladislav Lhotka за рецензирование.

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

Jie Dong

Huawei

Huawei Campus

No. 156 Beiqing Rd.

Beijing

100095

China

Email: jie.dong@huawei.com

Xiugang Wei

Huawei

Huawei Campus

No. 156 Beiqing Rd.

Beijing

100095

China

Email: weixiugang@huawei.com

Qin Wu

Huawei

101 Software Avenue

Yuhua District

Nanjing

210012

China

Email: bill.wu@huawei.com

Mohamed Boucadair

Orange

Rennes 35000

France

Email: mohamed.boucadair@orange.com

Anders Liu

Tecent

Yinke Building

38 Haidian St

Haidian District

Beijing

100080

China

Email: andersliu@tencent.com

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

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

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Interface to the Routing System.

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

5Provider Backbone Bridging – магистральные мосты провайдера.

6Virtual eXtensible Local Area Network – виртуальная расширяемая ЛВС.

7Link Layer Discovery Protocol – протокол обнаружения на канальном уровне.

8Network Configuration Protocol – протокол настройки сети.

Рубрика: RFC | Комментарии к записи RFC 8944 A YANG Data Model for Layer 2 Network Topologies отключены

RFC 8939 Deterministic Networking (DetNet) Data Plane: IP

image_print
Internet Engineering Task Force (IETF)                     B. Varga, Ed.
Request for Comments: 8939                                     J. Farkas
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                                L. Berger
                                                                D. Fedyk
                                                 LabN Consulting, L.L.C.
                                                               S. Bryant
                                                  Futurewei Technologies
                                                           November 2020

Deterministic Networking (DetNet) Data Plane: IP

Плоскость данных DetNet IP

PDF

Аннотация

Этот документ определяет работу плоскости данных детерминированной сети (DetNet1) для хостов и маршрутизаторов IP, обеспечивающих услуги DetNet для инкапсулированных в IP данных. Специфической для DetNet инкапсуляции не задается для поддержки потоков IP и вместо этого применяется информация из заголовков IP и вышележащего протокола для поддержки идентификации потоков и предоставления услуг DetNet. Документ основан на архитектуре DetNet (RFC 8655) и модели плоскости данных (RFC 8938).

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

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

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

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

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

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

Детерминированные сети DetNet обеспечивают возможность передачи индивидуальных или групповых потоков данных для приложений в реальном масштабе времени (real-time) с чрезвычайно низким уровнем потерь и гарантированным предельным (максимум) значением сквозной задержки. Общее описание основ и концепций DetNet дано в [RFC8655].

Этот документ задает работу плоскости данных DetNet для хостов и маршрутизаторов IP, предоставляющих услуги DetNet для инкапсулированных в IP данных. Специфической для DetNet инкапсуляции не задается для поддержки потоков IP и вместо этого применяется информация из заголовков IP и вышележащего протокола для поддержки идентификации потоков и предоставления услуг DetNet. Общие сведения и информация об управлении для всех плоскостей данных DetNet представлена в [RFC8938].

Архитектура DetNet моделирует связанные с DetNet функции плоскости данных как разделенные на два уровня – сервиса и пересылки. Подуровень сервиса служит для защиты сервиса DetNet (например, с помощью функций PRF4 и PEF5) и переупорядочения. Подуровень пересылки обеспечивает защиту от перегрузок (малые потери, гарантия низкой задержки и ограниченного нарушения порядка). Подуровень сервиса обычно требует для работы использования дополнительных полей заголовка (см. например, [DetNet-MPLS]). Поскольку связанных с DetNet полей не добавляется для поддержки потоков DetNet IP, поддерживаются лишь функции подуровня пересылки с использованием DetNet IP в соответствии с данным документом. Защита сервиса может обеспечиваться на уровне подсети с применением таких технологий, как MPLS [DetNet-MPLS] и Ethernet (в соответствии с IEEE 802.1 TSN) [IEEE802.1TSNTG].

Этот документ содержит обзор плоскости данных DetNet IP в разделе 3 и рассматривает вопросы предоставления услуг DetNet на основе плоскости данных DetNet IP в разделе 4. Раздел 5 описывает процедуры для хостов и маршрутизаторов, поддерживающих услуги DetNet на базе IP, а раздел 6 обобщает сведения, требуемые для идентификации отдельных потоков DetNet.

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

2.1. Используемые в документе термины

В этом документе используется терминология, представленная в архитектуре DetNet [RFC8655], и предполагается, что читатель знаком с этим документом.

2.2. Сокращения

DetNet Deterministic Networking – детерминированная сеть.

DN DetNet

Diffserv Differentiated Services – дифференцированное обслуживание.

DSCP Differentiated Services Code Point – код дифференцированного обслуживания.

L2 Layer 2 – канальный уровень.

L3 Layer 3сетевой уровень.

LSP Label Switched Path – путь с коммутацией по меткам.

MPLS Multiprotocol Label Switching – многопротокольная коммутация по меткам.

OAM Operations, Administration, and Maintenance – операции, администрирование и поддержка.

PCEP Path Computation Element Communication Protocol – коммуникационный протокол элементов расчета пути.

PEF Packet Elimination Function – функция исключения пакетов.

PREOF Packet Replication, Elimination, and Ordering Functions – функции репликации, исключения и упорядочения пакетов.

PRF Packet Replication Function – функция репликации пакетов.

QoS Quality of Service – качество обслуживания.

TSN Time-Sensitive Networking – чувствительные к времени сети.

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

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

3. Обзор плоскости данных DetNet IP

В этом документе описано, как IP используется узлами DetNet (т. е. хостами и маршрутизаторами) для идентификации потоков DetNet и обеспечения сервиса DetNet с плоскостью данных IP. С точки зрения плоскости данных используется сквозная модель IP. Как отмечено выше, применяется имеющаяся информация заголовка IP и вышележащего протокола для поддержки идентификации потоков DetNet и предоставления услуг. Базовые процедуры и управляющая информация для всех плоскостей данных DetNet описаны в [RFC8938].

Плоскость данных DetNet IP использует прежде всего идентификацию потока на основе кортежей 6-tuple, включающих данные из заголовков IP и вышележащего протокола. Термин 6-tuple в этом документе соответствует определению [RFC3290] и включает адреса отправителя и получателя, протокол IP, порты отправителя и получателя, а также DSCP. Сведения об использовании заголовков IP и кортежей 5-tuple для идентификации потоков и поддержки QoS приведены в [RFC3670]. В [RFC7657] также представлены полезные сведения по обеспечению Diffserv и идентификации потоков на основе кортежей. Отметим, что 6-tuple представляет собой кортеж 5-tuple с добавлением DSCP.

Для некоторых протоколов кортежи 5-tuple и 6-tuple использовать невозможно, поскольку информация о портах недоступна (например, в ICMP, IPsec, и ESP6). Такое возможно и для агрегата потоков. В этом случае используется меньшее число полей, например 3-tuple (2 адреса и протокол IP) и даже 2-tuple (вест трафик между парой адресов IP). Плоскость данных DetNet IP позволяет также сопоставление с полем IPv6 Flow Label [RFC8200].

Пакеты, не относящиеся к DetNet, и пакеты DetNet IP имеют одинаковый формат заголовка пакета при передаче. В общем случае используемые для идентификации потока поля пересылаются без изменений, однако стандартные изменения поля DSCP [RFC2474] не исключены.

Агрегирование потоков DetNet может быть реализовано за счет применения шаблонов, масок, списков, префиксов и диапазонов. Туннели IP также могут служить для поддержки агрегирования. В таких случаях предполагается, что понимающие DetNet промежуточные узлы будут обеспечивать услуги DetNet для агрегата с помощью механизмов выделения ресурсов и контроля перегрузок.

Конкретные процедуры, которые требуется реализовать на узле DetNet, поддерживающем этот документ, описаны в разделе 5. Плоскость контроллера DetNet (Controller Plane) [RFC8655] отвечает за обеспечение каждого узла информацией, требуемой для идентификации и обслуживания каждого потока DetNet.

Конечн. сист.                                            Конечн. сист.
DetNet IP      Транслятор                  Транслятор     DetNet IP
+----------+                                             +----------+
|Приложение|<------------- Сквозной сервис ------------->|Приложение|
+----------+  ............                 ............  +----------+
| Сервис   |<-: Сервис   :-- Поток DetNet--: Сервис   :->| Сервис   |
+----------+  +----------+                 +----------+  +----------+
|Пересылка |  |Пересылка |                 |Пересылка |  |Пересылка |
+--------.-+  +-.------.-+                 +-.---.----+  +-------.--+
         :Канал :       \      ,-----.      /     \   ,-----.   /
         +......+        +----[Подсеть]----+       +-[Подсеть]-+
                               `-----'                `-----'
        |<--------------------- DetNet IP --------------------->|

Рисунок 1. Простая сеть IP с поддержкой DetNet.


На рисунке 1 показана сеть IP с поддержкой DetNet. Поддерживающие DetNet конечные системы создают инкапсулированный в IP трафик, который идентифицируется в домене DetNet как поток DetNet на основе данных из заголовка IP. Трансляторам понятны требования к пересылке потока DetNet и они обеспечивают выделение ресурсов, интерфейса и узла для выполнения требований сервиса DetNet. Линии из точек вокруг блока «Сервис» на трансляторе показывают, что транзитные маршрутизаторы понимают сервис DetNet, но не реализуют функций подуровня сервиса DetNet, таких как PREOF. Следует отметить, что подсети могут представлять TSN, сеть MPLS или иную технологию, которая может передавать трафик DetNet IP.

Конечная        Краевой                     Краевой      Конечная
система IP      узел                        узел         система IP
+----------+   +.........+                 +.........+   +----------+
|Приложение|<--:Svc Proxy:-- Сервис E2E ---:Svc Proxy:-->|Приложение|
+----------+   +.........+                 +.........+   +----------+
|    IP    |<--:IP : :Svc:---- Поток IP----:Svc: :IP :-->|    IP    |
+----------+   +---+ +---+                 +---+ +---+   +----------+
|Пересылка |   |Fwd| |Fwd|                 |Fwd| |Fwd|   |Пересылка |
+--------.-+   +-.-+ +-.-+                 +-.-+ +-.-+   +---.------+
         : Канал :      \      ,-----.      /     /   ,-----. \ 
         +.......+       +----[Подсеть]----+      +--[Подсеть]-+
                               `-----'                `-----'
      |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->|

Рисунок 2. Конечные системы без поддержки DetNet в домене DetNet IP.


На рисунке 2 приведен вариант рисунка 1, где конечные системы не понимают DetNet. В этом случае краевые узлы на границе домена DetNet обеспечивают посреднические услуги DetNet для приложений конечных точек путем создания и завершения сервиса DetNet для потоков IP от приложений. Для идентификации потоков DetNet может служить информация из заголовков или подход, описанный в параграфе 4.4. Агрегирование потоков DetNet.

Отметим, что конечные системы IP DetNet могут взаимодействовать через сеть DetNet IP с конечными системами IP.

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

Отметим, что работа конечных систем IEEE 802.1 TSN через сети IP с поддержкой DetNet не описана в этом документе. Описание TSN over MPLS приведено в [DetNet-TSN-over-MPLS].

4. Плоскость данных DetNet IP

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

4.1. Конечные точки

Потоки данных, требующие сервиса DetNet, создаются и завершаются в конечных точках. Этот документ имеет дело лишь с конечными системами IP. Протокол, используемый конечной системой IP, зависит от приложения и конечная система взаимодействует с другой конечной системой (партнером). DetNet использует идентификацию потоков IP на основе кортежей 6-tuple, поэтому DetNet нужно знать не только формат заголовка IP, но и значение следующего протокола в пакете IP (5.1.1.3. Поля IPv4 Protocol и IPv6 Next Header).

Для не знающих DetNet конечных систем IP внутри домена DetNet требуются посреднические функции уровня сервиса.

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

Важным дополнительным вопросом для понимающих DetNet конечных систем является предотвращение фрагментации IP. Полная идентификация потоков на основе 6-tuple невозможна для фрагментов IP, поскольку они не включают транспортных заголовков и сведений о портах. Поэтому для приложений и/или конечных систем важно использовать размер пакетов IP, позволяющий избежать фрагментации в сети при передаче потоков DetNet. Максимальный размер пакетов можно узнать с помощью Path MTU Discovery [RFC1191] [RFC8201] или от плоскости контроллера. Отметим, что механизм Path MTU Discovery основан на пакетах ICMP, которые могут идти по иному пути, нежели отдельный поток DetNet.

Для максимального использования имеющихся механизмов понимающим DetNet приложениям и конечным системам не следует смешивать трафик DetNet с прочим трафиком в рамках одного кортежа 5-tuple.

4.2. Домен DetNet

Как правило, от домена DetNet IP требуется поддержка пересылки любого потока DetNet, указанного кортежем IP 6-tuple. Иное поведение будет ограничивать число идентификаторов потоков 6-tuple, которые могут применять конечные системы. С практической точки зрения это означает, что все узлы на сквозном пути потоков DetNet должны согласовать применяемые для идентификации потоков поля. Возможным следствием отсутствия такого согласия будут помехи, создаваемые одними потоками для других, и неожиданная обработка трафика.

С точки зрения типа подключения возможны два варианта:

  1. подключение DN – конечная система напрямую соединяется с краевым узлом или находится за пределами подсети (ES1 и ES2 на рисунке 3);

  2. интеграция с DN – конечная система является частью домена DetNet (ES3 на рисунке 3).

Конечные системы L3 (IP) могут применять любой из этих вариантов подключения. Домен DetNet позволяет взаимодействовать любым конечным системам с одинаковым форматом инкапсуляции независимо от типа подключения и свойств DetNet. Подключенные к DN конечные системы не знают о домене DetNet и его формате инкапсуляции. Примеры подключений даны на рисунке 3.

                                   ____+----+
           +----+        _____    /    | ES3|
           | ES1|____   /     \__/     +----+___
           +----+    \ /                        \
                      +                          |
              ____     \                        _/
+----+     __/    \     +__  DetNet IP domain  /
| ES2|____/  L2/L3 |___/   \         __     __/
+----+    \_______/         \_______/  \___/

Рисунок 3. Типы подключения конечных систем L3.


Внутри домена DetNet маршрутизаторы IP с поддержкой DetNet соединены между собой каналами и подсетями для поддержки сквозной доставки потоков DetNet. С точки зрения архитектуры DetNet эти маршрутизаторы являются ретрансляторами DetNet, поскольку они должны понимать сервис DetNet. Такие маршрутизаторы идентифицируют потоки DetNet на основе кортежей IP 6-tuple и обеспечивают обработку, требуемую сервисом DetNet, на самом узле и в подключенных к нему подсетях.

Это решение обеспечивает сквозные функции DetNet, но не делает этого на уровне соединений или подсетей. Защита от перегрузок, контроль задержки и выделение ресурсов (очереди, правила, формовка) поддерживаются с использованием механизмов базового канала или подсети. Однако сквозная защита сервиса (PRF и PEF) не обеспечивается на уровне DetNet и должна предоставляться на уровне соединения (базовый канал L2) и подсети.

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

     <-------------------- DetNet IP ------------------------>
                                 ______
                       ____     /      \__
            ____      /     \__/          \___   ______
+----+   __/    +====+                       +==+      \     +----+
|src |__/ Sub-N1 )   |                       |  \ Sub-N3\____| dst|
+----+  \_______/    \        Подсеть 2      |   \______/    +----+
                      \_                    _/
                        \         __     __/
                         \_______/  \___/


          +---+        +---------E--------+      +-----+
+----+    |   |        |         |        |      |     |      +----+
|src |----R   E--------R     +---+        E------R     E------+ dst|
+----+    |   |        |     |            |      |     |      +----+
          +---+        +-----R------------+      +-----+

Рисунок 4. Репликация и исключение в подсетях для DetNet IP.


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

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

Отметим, что отсутствие смешения трафика DetNet с прочим в рамках одного кортежа 5-tuple, как указано выше, позволяет упростить фильтры 5-tuple, применяемые на краях сети DetNet для предотвращения выхода трафика DetNet, не реагирующего на перегрузки, за пределы домена DetNet.

4.3. Подуровень пересылки

4.3.1. Класс обслуживания

Класс обслуживания (CoS) для потоков DetNet передаваемых в пакетах IPv4 и IPv6, обеспечивается стандартным полем DSCP [RFC2474] и связанными с ним механизмами.

Дополнительный вопрос для узлов DetNet, поддерживающих услуги CoS, заключается в том, что они должны обеспечить отсутствие влияния классов обслуживания CoS на механизмы защиты от перегрузки и контроля задержек, применяемые для DetNet QoS. Это похоже на требование к маршрутизаторам MPLS LSR7, где CoS LSP не должны влиять на ресурсы, выделенные для TE LSP [RFC3473].

4.3.2. Качество обслуживания

Качество обслуживания (QoS) для потоков сервиса DetNet, передаваемых по IP, должно обеспечиваться локально знающими о DetNet узлами и маршрутизаторами, поддерживающими потоки DetNet. Поддержка зависит от базовых сетевых уровней, таких как 802.1 TSN. Использование внутренних механизмов управления трафиком на узлах для обеспечения QoS потокам DetNet с инкапсуляцией IP выходит за рамки этого документа. С точки зрения инкапсуляции кортеж 6-tuple (5-tuple и DSCP) и, возможно, метка потока однозначно указывает поток DetNet IP.

Пакеты, идентифицированные как часть потока DetNet IP, но не относящиеся к выполненному резервированию, могут нарушать QoS для корректно зарезервированных потоков DetNet, используя выделенные тем ресурсы. Поэтому узлы сети DetNet должны предотвращать использование такими потоками ресурсов, не выделенных DetNet. Имеется много методов, которые реализация может использовать для защиты обслуживания зарезервированных потоков DetNet, включая перечисленные ниже.

  • Обработка пакетов, связанных с незавершенным резервированием, как не относящихся к DetNet.

  • Отбрасывание пакетов, связанных с незавершенным резервированием.

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

4.3.3. Выбор пути

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

При пересылке не относящихся к DetNet пакетов IP обычно предполагается такая же последовательность next hop, т. е. для данного кортежа 5-tuple (в некоторых случаях, например, [RFC5120] — 6-tuple) будет использован тот же путь. Использование разных next hop для разных 5-tuples не имеет особого значения для приложений, понимающих DetNet.

Следует соблюдать осторожность при использовании разных next hop для одного кортежа 5-tuple. Как отмечено в [RFC7657], возможно неожиданное поведение когда в потоке приложения с данным 5-tuple происходит нарушение порядка в результате отправки по разным путям. Требуется понимать роль приложения и транспортного протокола при использовании разных next hop для одного кортежа 5-tuple, если это предполагается. Отметим, что это лишь косвенно влияет на выбор путей для потоков DetNet и данный документ.

4.4. Агрегирование потоков DetNet

Как описано в [RFC8938], возможность объединять отдельные потоки и связанное с этим управление ресурсами является важным способом повышения уровня расширяемости за счет уменьшения числа состояний на интервал пересылки. Агрегирование в плоскости данных DetNet IP может происходить на одном узле, когда тот поддерживает состояния для агрегированных и индивидуальных потоков. Это также может выполняться между узлами, когда один поддерживает лишь состояние для агрегата, а другой – для всех или части объединенных потоков. В любом случае функции управления и поддержки агрегирования должны обеспечивать адекватную настройку и выделение ресурсов для комбинации потребностей в обслуживании отдельных потоков. Поскольку DetNet заботится о задержках и их вариациях, требуется учитывать не только пропускную способность.

С точки зрения одного узла агрегирование потоков IP влияет на идентификацию потоков и выделение ресурсов в плоскости данных DetNet IP. Как обсуждалось выше, для идентификации потока IP служат кортежи IP 6-tuple. Потоки DetNet IP могут объединяться с использованием любого из полей 6-tuple, а также метки потока. Использование префиксов, списков и диапазонов значений позволяет узлу DetNet идентифицировать агрегированные потоки DetNet. С точки зрения выделения ресурсов узлы DetNet должны предоставлять обслуживание на уровне агрегированного потока, а не его компонентов.

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

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

4.5. Двухсторонний трафик

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

Механизмы управления и администрирования должны поддерживать двухсторонние потоки, но спецификация таких механизмов выходит за рамки документа. Пример решения для плоскости управления MPLS можно найти в [RFC7551].

5. Процедуры плоскости данных DetNet IP

В этом разделе описаны процедуры плоскости данных DetNet IP, которые разделены на три категории – идентификация потоков, пересылка и обработка трафика. Идентификация потоков включает процедуры, относящиеся к сопоставлению заголовков IP и вышележащего протокола с данными потока DetNet (состояние) и требованиями сервиса. Иногда идентификацию потоков называют классификацией трафика (например, в [RFC5777]). Пересылка включает процедуры, относящиеся к выбору следующего интервала (next-hop) и доставке пакетов. Обработка трафика включает процедуры, связанные с предоставлением потокам DetNet требуемого обслуживания.

Процедуры организации и работы плоскости данных DetNet IP вносят требования к системам управления и поддержки для потоков DetNet, также упоминаемые в этом разделе. В частности, раздел указывает множество информационных элементов, которые должны поддерживаться узлом DetNet на интерфейсах управления и поддержки. Конкретные механизмы такой поддержки выходят за рамки этого документа и приведена лишь сводка требований к информации, связанной с управлением и поддержкой. В сводке не задаются уровни требований, поскольку она относится к будущим механизмам, таким как определяемые моделями YANG [DetNet-YANG].

5.1. Процедуры идентификации потоков DetNet IP

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

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

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

5.1.1. Данные заголовка IP

Реализации этого документа должны поддерживать идентификацию потоков DetNet на основе заголовков IP. Заголовок IPv4 определен в [RFC0791], IPv6 – в [RFC8200].

5.1.1.1. Поле адреса отправителя

Реализации этого документа должны поддерживать идентификацию потоков DetNet на основе поля Source Address8 в пакете IP. Реализациям следует поддерживать для этого поля сопоставление по наибольшей длине префикса (см. [RFC1812] и [RFC7608]). Отметим, что сопоставление с префиксом размера 0 означает игнорирование поля.

5.1.1.2. Поле адреса получателя

Реализации этого документа должны поддерживать идентификацию потоков DetNet на основе поля Destination Address в пакете IP. Реализациям следует поддерживать для этого поля сопоставление по наибольшей длине префикса (см. [RFC1812] и [RFC7608]). Отметим, что сопоставление с префиксом размера 0 означает игнорирование поля.

5.1.1.3. Поля IPv4 Protocol и IPv6 Next Header

Реализации этого документа должны поддерживать идентификацию потоков DetNet на основе поля IPv4 Protocol при обработке пакетов IPv4 и поля IPv6 Next Header при обработке пакетов IPv6. Это включает значение следующего протокола, определенное в параграфе 5.1.2, и другие значения, в том числе 0. Реализациям следует поддерживать возможность игнорировать это поле для конкретного потока DetNet.

5.1.1.4. Поля IPv4 Type of Service и IPv6 Traffic Class

Эти поля служат для поддержки дифференцированного обслуживания [RFC2474] [RFC2475]. Реализации этого документа должны поддерживать идентификацию потоков DetNet на основе поля DSCP в поле IPv4 Type of Service для пакетов IPv4 и поля DSCP в поле IPv6 Traffic Class для пакетов IPv6. Реализации должны поддерживать сопоставление полей DSCP со списком возможных значений при идентификации конкретного потока DetNet. Реализациям следует поддерживать возможность игнорировать это поле для конкретного потока DetNet.

5.1.1.5. Поле IPv6 Flow Label

Реализациям этого документа следует поддерживать идентификацию потоков DetNet на основе поля IPv6 Flow Label. Поддерживающие это реализации должны разрешать возможность игнорировать поле для конкретного потока DetNet. При использовании поля для идентификации конкретного потока DetNet реализация может исключить поле IPv6 Next Header и данные следующего заголовка из процесса идентификации потока DetNet.

5.1.2. Другая информация из заголовков

Реализации этого документа должны поддерживать идентификацию потоков DetNet на основе информации из заголовков, указанной в этом разделе. Определена поддержка для потоков TCP, UDP, ICMP и IPsec, а в будущем список протоколов может быть расширен.

5.1.2.1. TCP и UDP

Идентификация потоков DetNet для TCP [RFC0793] и UDP [RFC0768] выполняется на основе полей Source Port и Destination Port в заголовке каждого пакета. Эти поля используют одинаковые формате и для них применяются общие процедуры идентификации потоков DetNet.

Определенные в этом параграфе правила применимы только к полям IPv4 Protocol и IPv6 Next Header, содержащим определенные IANA значения для UDP и TCP.

5.1.2.1.1. Поле Source Port

Реализации этого документа должны поддерживать идентификацию потоков DetNet на основе поля Source Port в заголовках TCP и UDP. Реализации должны поддерживать идентификацию потоков на основе точного совпадения значений, а также следует поддерживать сопоставление с диапазоном значений. Реализации должны обеспечивать возможность игнорировать это поле для конкретного потока DetNet.

5.1.2.1.2. Поле Destination Port

Реализации этого документа должны поддерживать идентификацию потоков DetNet на основе поля Destination Port в заголовках TCP и UDP. Реализации должны поддерживать идентификацию потоков на основе точного совпадения значений, а также следует поддерживать сопоставление с диапазоном значений. Реализации должны обеспечивать возможность игнорировать это поле для конкретного потока DetNet.

5.1.2.2. ICMP

Идентификация потоков DetNet для ICMP [RFC0792] обеспечивается на основе номера протокола в заголовке IP. Отметим, что тип ICMP не применяется для идентификации потоков.

5.1.2.3. IPsec AH и ESP

Протоколы IPsec Authentication Header (AH) [RFC4302] и Encapsulating Security Payload (ESP) [RFC4303] используют общий формат для поля Security Parameters Index (SPI) field. Реализации должны поддерживать идентификацию на основе точного совпадения значений. Реализациям следует поддерживать возможность игнорировать это поле для конкретного потока DetNet.

Определенные в этом параграфе правила применимы только к полям IPv4 Protocol и IPv6 Next Header, содержащим определенные IANA значения для AH и ESP.

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

Общие требования к узлам IP заданы в [RFC1122], [RFC1812], [RFC8504] и данный документ их не меняет. DetNet влияет на типичный процесс выбора следующего этапа пересылки (next-hop). В частности, реализациям этого документа нужно использовать данные управления и поддержки для выборе одного или нескольких выходных интерфейсов в качестве следующего этапа пересылки пакетов, связанных с потоком DetNet. Конкретные данные управления и поддержки будут определены в будущих документах, например, [DetNet-YANG].

Использование множества путей или каналов (например, ECMP) для поддержки одного потока DetNet нерекомендуется. ECMP можно использовать с не относящимися к DetNet потоками в домене DetNet.

Сказанное выше применимо к функциям управления и поддержки, которые будут определены для реализации этого требования, например, [DetNet-YANG].

5.3. Процедуры обработки трафика DetNet IP

Реализации этого документа должны обеспечивать для потоков DetNet обработку трафика, предусмотренную конфигурацией или плоскостью контроллера (например, через [DetNet-YANG]). Общие сведения о сервисе DetNet можно найти в [DetNet-Flow-Info]. Типичные механизмы обеспечения разной обработки для разных потоков включают выделение системных ресурсов (таких как очереди и буферы) и предоставление соответствующих параметров (формовка и правила). Поддержка также может быть обеспечена за счет базовой сетевой технологии, такой как MPLS [DetNet-IP-over-MPLS] или IEEE 802.1 TSN [DetNet-IP-over-TSN]. Другие механизмы, кроме применяемых в случае TSN, выходят за рамки этого документа.

6. Поддержка и управление

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

  • Поле IPv4 или IPv6 Source Address.

  • Размер префикса адреса отправителя IPv4 или IPv6, где значение 0 указывает игнорирование поля Source Address.

  • Поле IPv4 или IPv6 Destination Address.

  • Размер префикса адреса получателя IPv4 или IPv6, где значение 0 указывает игнорирование поля Destination Address.

  • Поле IPv4 Protocol. Разрешен ограниченный набор значений, желательна возможность игнорировать поле.

  • Поле IPv6 Next Header. Разрешен ограниченный набор значений, желательна возможность игнорировать поле.

  • Для полей IPv4 Type of Service и IPv6 Traffic Class:

    • используется ли поле DSCP для классификации потока (не обязательно);

    • при использовании DSCP идентификационные данные (для этого потока) включают список применяемых потоком значение DSCP.

  • Поле IPv6 Flow Label (не обязательно). При использовании этого поля оно может служить заменой сопоставления с полем Next Header.

  • Порт отправителя TCP и UDP Source Port. Требуется поддержка точного и шаблонного совпадения, возможно сопоставление с диапазоном.

  • Порт отправителя TCP и UDP Destination Port. Требуется поддержка точного и шаблонного совпадения, возможно сопоставление с диапазоном.

  • Поле IPsec Header SPI. Требуется поддержка точного совпадения и рекомендуется поддерживать шаблоны.

  • Для конечных систем – (необязательный) максимальный размер пакетов IP, который следует применять для данного исходящего потока DetNet IP.

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

Реализация должна поддерживать упорядочение набора информации, служащей для идентификации отдельного потока DetNet. Это может применяться, например, для предоставления услуг DetNet конкретному потоку UDP с определенной комбинацией Source Port и Destination Port с одновременным предоставлением других услуг агрегату из всех прочих потоков с таким же значением UDP Destination Port.

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

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

Вопросы безопасности DetNet подробно перечислены в [DetNet-Security], а более общее рассмотрение их приведено в [RFC8655]. В этом разделе рассматриваются вопросы безопасности, специфичные для плоскости данных DetNet IP.

Уникальными для DetNet являются аспекы безопасности, связанные с обеспечением конкретных требований QoS для DetNet, предназначенных в первую очередь для доставки пакетов потока с минимально возможными потерями и ограниченной сквозной задержкой. Достижение малых потерь и ограниченной задержки может стать невозможным перед лицом серьезного противника, такого как указан в модели угроз Internet из BCP 72 [RFC3552], который может произвольно отбрасывать или задерживать любой или весь трафик. Чтобы представить значимые вопросы безопасности, здесь рассматривается не столь сильный противник, который не может контролировать физические каналы домена DetNet, но способен управлять узлом сети в домене DetNet.

Основным вопросом для плоскости данных DetNet является поддержка целостности и предоставление услуг DetNet, проходящих через сеть DetNet. Поскольку в плоскости данных DetNet IP нет специфичных для DetNet полей, целостность и конфиденциальность потоков приложений могут быть защищены любыми средствами, предоставляемыми базовой технологией. Например, может применяться шифрование, такое как обеспечиваемое IPsec [RFC4301] для потоков IP или базовой сеть с использованием MACsec [IEEE802.1AE-2018] при передаче IP в потоках Ethernet (L2).

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

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

Для обеспечения непрерывной доступности сервиса DetNet могут быть приняты меры против атак на службы (DoS) и атак с задержками. Для защиты от DoS-атак избыточный трафик от вредоносных или некорректно работающих устройств можно предотвратить или ослабить, например, с помощью имеющихся механизмов, таких как правила и формовка на входе в домен DetNet или на краю домена IEEE 802.1 TSN. Для предотвращения вредоносной задержки пакетов DetNet за пределами домена DetNet определения технологии DetNet могут смягчать перехват и изменение в пути с участием человека (MITM9-атака), например за счет проверки подлинности и полномочий устройств в домене DetNet.

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

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

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

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

[RFC0768] Postel, J., “User Datagram Protocol”, STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0791] Postel, J., “Internet Protocol”, STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC0792] Postel, J., “Internet Control Message Protocol”, STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.

[RFC0793] Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC1812] Baker, F., Ed., “Requirements for IP Version 4 Routers”, RFC 1812, DOI 10.17487/RFC1812, June 1995, <https://www.rfc-editor.org/info/rfc1812>.

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

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4302] Kent, S., “IP Authentication Header”, RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.

[RFC4303] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, “IPv6 Prefix Length Recommendation for Forwarding”, BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, <https://www.rfc-editor.org/info/rfc7608>.

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

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, “Deterministic Networking Architecture”, RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.

[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, “Deterministic Networking (DetNet) Data Plane Framework”, RFC 8938, DOI 10.17487/RFC8938, November 2020, <https://www.rfc-editor.org/rfc/rfc8938>.

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

[DetNet-Flow-Info] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, “DetNet Flow Information Model”, Work in Progress, Internet-Draft, draft-ietf-detnet-flow-information-model-11, 21 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-11>.

[DetNet-IP-over-MPLS] Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J. Korhonen, “DetNet Data Plane: IP over MPLS”, Work in Progress, Internet-Draft, draft-ietf-detnet-ip-over-mpls-09, 11 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-09>.

[DetNet-IP-over-TSN] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, “DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)”, Work in Progress, Internet-Draft, draft-ietf-detnet-ip-over-tsn-04, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-detnet-ip-over-tsn-04>.

[DetNet-MPLS] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, “DetNet Data Plane: MPLS”, Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-13, 11 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-13>.

[DetNet-Security] Grossman, E., Ed., Mizrahi, T., and A. Hacker, “Deterministic Networking (DetNet) Security Considerations”, Work in Progress, Internet-Draft, draft-ietf-detnet-security-12, 2 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-security-12>.

[DetNet-TSN-over-MPLS] Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D. Fedyk, “DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS”, Work in Progress, Internet-Draft, draft-ietf-detnet-tsn-vpn-over-mpls-04, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-over-mpls-04>.

[DetNet-YANG] Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, “Deterministic Networking (DetNet) Configuration YANG Model”, Work in Progress, Internet-Draft, draft-ietf-detnet-yang-09, 16 November 2020, <https://tools.ietf.org/html/draft-ietf-detnet-yang-09>.

[IEEE802.1AE-2018] IEEE, “IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security”, IEEE 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December 2018, <https://ieeexplore.ieee.org/document/8585421>.

[IEEE802.1TSNTG] IEEE, “Time-Sensitive Networking (TSN) Task Group”, <https://1.ieee802.org/tsn/>.

[RFC1122] Braden, R., Ed., “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, “An Informal Management Model for Diffserv Routers”, RFC 3290, DOI 10.17487/RFC3290, May 2002, <https://www.rfc-editor.org/info/rfc3290>.

[RFC3473] Berger, L., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions”, RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.

[RFC3552] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations”, BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.

[RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, “Information Model for Describing Network Device QoS Datapath Mechanisms”, RFC 3670, DOI 10.17487/RFC3670, January 2004, <https://www.rfc-editor.org/info/rfc3670>.

[RFC5120] Przygienda, T., Shen, N., and N. Sheth, “M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)”, RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.

[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, “Traffic Classification and Quality of Service (QoS) Attributes for Diameter”, RFC 5777, DOI 10.17487/RFC5777, February 2010, <https://www.rfc-editor.org/info/rfc5777>.

[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., “RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)”, RFC 7551, DOI 10.17487/RFC7551, May 2015, <https://www.rfc-editor.org/info/rfc7551>.

[RFC7657] Black, D., Ed. and P. Jones, “Differentiated Services (Diffserv) and Real-Time Communication”, RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., “Path MTU Discovery for IP version 6”, STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[RFC8504] Chown, T., Loughney, J., and T. Winters, “IPv6 Node Requirements”, BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.

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

Авторы благодарят Pat Thaler, Norman Finn, Loa Andersson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang и Carlos J. Bernardos за их вклад в работу. David Black был техническим советником рабочей группы DetNet во время создания этого документа и предоставил много полезных замечаний. Комментарии от IESG предоставили Murray Kucherawy, Roman Danyliw, Alvaro Retana, Benjamin Kaduk, Rob Wilton и Érik Vyncke.

Участники работы

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

Jouni Korhonen

Email: jouni.nospam@gmail.com

Andrew G. Malis

Malis Consulting

Email: agmalis@gmail.com

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

Balázs Varga (editor)

Ericsson

Budapest

Magyar Tudosok krt. 11.

1117

Hungary

Email: balazs.a.varga@ericsson.com

János Farkas

Ericsson

Budapest

Magyar Tudosok krt. 11.

1117

Hungary

Email: janos.farkas@ericsson.com

Lou Berger

LabN Consulting, L.L.C.

Email: lberger@labn.net

Don Fedyk

LabN Consulting, L.L.C.

Email: dfedyk@labn.net

Stewart Bryant

Futurewei Technologies

Email: sb@stewartbryant.com

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

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

nmalykh@protocols.ru

1Deterministic Networking.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Packet Replication Function – функция репликации пакетов.

5Packet Elimination Function – функция исключения пакетов.

6Encapsulating Security Payload – инкапсуляция данных защиты.

7Label Switching Router – маршрутизатор с коммутацией по меткам.

8Отметим, что сравниваться могут любые адреса IP, включая групповые адреса получателей.

9Man-in-the-middle – «человек в середине».

Рубрика: RFC | Комментарии к записи RFC 8939 Deterministic Networking (DetNet) Data Plane: IP отключены

RFC 8938 Deterministic Networking (DetNet) Data Plane Framework

image_print
Internet Engineering Task Force (IETF)                     B. Varga, Ed.
Request for Comments: 8938                                     J. Farkas
Category: Informational                                         Ericsson
ISSN: 2070-1721                                                L. Berger
                                                 LabN Consulting, L.L.C.
                                                                A. Malis
                                                        Malis Consulting
                                                               S. Bryant
                                                  Futurewei Technologies
                                                           November 2020

Deterministic Networking (DetNet) Data Plane Framework

Модель плоскости данных детерминированных сетей (DetNet)

PDF

Аннотация

В этом документе описана общая схема плоскости данных детерминированных сетей (DetNet1). Докумен охватывает концепции и вопросы, относящиеся к любой спецификации плоскости данных DetNet, а также включает общие вопросы, относящиеся к плоскости контроллера (Controller Plane).

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

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

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

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

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

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

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

1. Введение

Детерминированные сети DetNet обеспечивают возможность передачи определенных индивидуальных или групповых потоков данных для приложений в реальном масштабе времени (real-time) с чрезвычайно низким уровень потерь и гарантированным предельным (максимум) значением сквозной задержки. Общее описание основ и концепций DetNet дано в [RFC8655].

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

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

Как часть функций сервисного подуровня в этом документе описаны типовые операции плоскости данных DetNet, включая функции репликации (Packet Replication Function или PRF), исключения (Packet Elimination Function или PEF) и упорядочения (Packet Ordering Function или POF) пакетов внутри подуровня. Описан также подуровень пересылки.

Как определено в [RFC8655], потоки DetNet могут передаваться на основе технологий, способных обеспечить требуемые характеристики услуг для DetNet. Например, потоки DetNet MPLS могут передаваться через подсети IEEE 802.1 Time-Sensitive Networking (TSN) [IEEE802.1TSNTG], однако поддержка IEEE 802.1 TSN не требуется в DetNet. Вытеснение кадров TSN является примером свойства уровня пересылки, которое обычно не используется в других технологиях пересылки. Большинство преимуществ DetNet можно обеспечить при работе на основе канальных уровней, не приспособленных специально для поддержки всех возможностей TSN, но для таких сетей и смешанного трафика характеристики задержки и ее вариаций могут различаться из-за внутренних свойств подуровня пересылки.

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

В документе также рассмотрены базовые концепции, относящиеся к уровню контроллера и OAM4. Детали OAM плоскости данных выходят за рамки документа.

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

2.1. Используемые в документе термины

В этом документе используется терминология, представленная в архитектуре DetNet [RFC8655], и предполагается, что читатель знаком с этим документом.

2.2. Сокращения

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

BGP Border Gateway Protocol – протокол междоменной маршрутизации (граничного шлюза).

CoS Class of Service – класс обслуживания.

d-CW DetNet Control Word – управляющее слово DetNet.

DetNet Deterministic Networking – детерминированная сеть.

DN DetNet

GMPLS Generalized Multiprotocol Label Switching – обобщенная коммутация по меткам.

GRE Generic Routing Encapsulation – базовая инкапсуляция маршрутных данных.

IPsec IP Security – защита IP.

L2 Layer 2 – канальный уровень.

LSP Label Switched Path – путь с коммутацией по меткам.

MPLS Multiprotocol Label Switching – многопротокольная коммутация по меткам.

OAM Operations, Administration, and Maintenance – операции, администрирование и поддержка.

PCEP Path Computation Element Communication Protocol – коммуникационный протокол элементов расчета пути.

PEF Packet Elimination Function – функция исключения пакетов.

POF Packet Ordering Function – функция упорядочения пакетов.

PREOF Packet Replication, Elimination, and Ordering Functions – функции репликации, исключения и упорядочения пакетов.

PRF Packet Replication Function – функция репликации пакетов.

PSN Packet Switched Network – сеть с коммутацией пакетов.

QoS Quality of Service – качество обслуживания.

S-Label DetNet “service” label – метка сервиса DetNet.

TDM Time-Division Multiplexing – мультиплексирование с разделением по времени.

TSN Time-Sensitive Networking – чувствительные к времени сети.

YANG Yet Another Next Generation

3. Обзор плоскости данных DetNet

В этом документе описано, как потоки приложений (App-flow) [RFC8655] передаются через сети DetNet. Архитектура DetNet [RFC8655] моделирует относящиеся к DetNet функции плоскости данных как разделенные на два подуровня – сервис и пересылка.

На рисунке 1 из [RFC8655] показана логическая схема сервиса DetNet с двумя подуровнями.

   |Пакет, проходящий|        ^ Пакет, проходящий ^
   v  вниз по стеку  v        |  вверх по стеку   |
+-----------------------+   +-----------------------+
|       Источник        |   |      Получатель       |
+-----------------------+   +-----------------------+
|   Подуровень сервиса: |   | Подуровень сервиса:   |
|   Упорядочение пакетов|   | Исключение дубликатов |
|   Репликация потоков  |   | Слияние потоков       |
|   Кодирование пакетов |   | Декодирование пакетов |
+-----------------------+   +-----------------------+
| Подуровень пересылки: |   | Подуровень пересылки: |
| Выделение ресурсов    |   | Выделение ресурсов    |
| Явные маршруты        |   | Явные маршруты        |
+-----------------------+   +-----------------------+
|     Нижние уровни     |   |     Нижние уровни     |
+-----------------------+   +-----------------------+
            v                           ^
             \_________________________/

Рисунок 1. Стек протоколов плоскости данных DetNet.


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

Подуровень пересылки обеспечивает связанные с QoS функции, требуемые для потоков DetNet. Это можно делать напрямую, используя очереди и методы организации трафика, или с помощью базового уровня. Например, можно использовать возможности IEEE 802.1 TSN [IEEE802.1TSNTG]. Подуровень пересылки использует буферные ресурсы для очередей пакетов и выделения пропускной способности.

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

Метод создания экземпляров каждого из уровней зависит от конкретной плоскости данных DetNet с возможностью использования множества подходов для данного типа сети.

3.1. Характеристики плоскости данных

Двумя основными характеристиками плоскости данных являются технология и инкапсуляция, рассмотренные ниже.

3.1.1. Технология плоскости данных

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

3.1.2. Инкапсуляция

DetNet кодирует конкретные атрибуты потока (отождествление и порядковый номер) в пакетах. Например, в DetNet IP инкапсуляция не применяется и нет порядковых номеров, в DetNet MPLS связанная с DetNet информация может явно добавляться в пакеты в форме S-Label и d-CW [DetNet-MPLS].

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

                        +-----+
                        | TSN |
   +-------+          +-+-----+-+
   | DN IP |          | DN MPLS |
+--+--+----+----+   +-+---+-----+-+
| TSN | DN MPLS |   | TSN | DN IP |
+-----+---------+   +-----+-------+

Рисунок 2. Примеры сервиса DetNet.


Использование инкапсуляции также требуется, если плоскости данных DetNet нужна дополнительная информация (метаданные) и (1) нет возможности включить ее в клиентские пакеты данных или (2) спецификация плоскости данных клиента не позволяет изменять пакеты для включения в них дополнительных данных. Примером таких метаданных является включение порядковых номеров, требуемых для PREOF.

Инкапсуляция может также служить для передачи или агрегирования потоков в оборудовании с ограниченными возможностями DetNet.

3.2. Метаданные DetNet

Плоскость данных DetNet может предоставлять и передавать два типа данных:

  1. идентификаторы потоков (Flow-ID);

  2. порядковые номера.

Плоскость данных DetNet поддерживает Flow-ID (для идентификации потока или агрегата потоков) и/или порядковый номер (для PREOF) в каждом потоке DetNet. Flow-ID применяется подуровнями сервиса и пересылки, а порядковый номертолько сервисным уровнем. Метаданные могут также применяться для OAM и измерений в операциях плоскости данных DetNet.

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

Явное включение метаданных возможно за счет использования опций или заголовков расширения IP. Новые опции IP стандартизовать или реализовать в работающей сети уже практически невозможно и это дальше не рассматривается. Заголовки расширения IPv6 становятся популярными в текущих разработках IPv6, в частности, вместе с сегментной маршрутизацией IPv6 (Segment Routing или SRv6) и IP OAM. Разработка новых или изменение имеющихся заголовков расширения IPv6 доступны в наборе инструментов разработчика плоскости данных DetNet IP.

Явное включение метаданных в пакет IP также возможно за счет добавления стека меток MPLS и MPLS d-CW с использованием одного из методов для передачи MPLS по протоколу IP [DetNet-MPLS-over-UDP-IP]. Это более подробно рассматривается в параграфе 3.5.5. Подсети.

Неявные метаданные можно включить в IP путем использования парадигмы сетевого программирования [SRv6-Network-Prog], где суффикс адреса IPv6 служит для представления дополнительной информации, используемой сетью принимающего хоста.

Примером явных данных MPLS являются порядковые номера, используемые PREOF, и даже случай включения всей требуемой информации в стек меток DetNet-over-MPLS (d-CW и DetNet S-Label).

3.3. Плоскость данных DetNet IP

Плоскость данных DetNet IP может работать естественным способом или с использованием инкапсуляции. Требованиям DetNet удовлетворяет много типов инкапсуляции IP и предполагается возможность использования нескольких типов (например, GRE, IPsec).

Одним из вариантов работы плоскости данных DetNet IP без инкапсуляции является использование идентификации потоков на основе кортежей 6-tuple (данные из заголовка IP и вышележащего уровня). Общие сведения об использовании заголовков IP и кортежей 6-tuple для идентификации потоков и поддержки QoS можно найти в [RFC3670]. Дополнительным полем 6-tuple является поле DSCP в пакете. В [RFC7657] представлены полезные сведения о дифференцированных услугах (Diffserv) и идентификации потоков на основе кортежей. Агрегирование потоков DetNet может быть обеспечено за счет применения шаблонов, масок, префиксов и диапазонов. Работа этого метода подробно описана в [RFC8939].

Плоскость пересылки DetNet может использовать явные маршруты и возможности организации трафика для организации подуровня пересылки, отвечающего за выделение ресурсов и явные маршруты. Такую информацию можно включить в естественные пакеты IP явно или неявно.

3.4. Плоскость данных DetNet MPLS

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

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

В случаях, где требуются метаданные для обработки пакетов с инкапсуляцией MPLS на подуровне сервиса, можно применять d-CW [DetNet-MPLS]. Хотя управляющие слова d-CW часто имеют размер 32 бита, это не является архитектурным ограничением на размер структуры и задается лишь требование, чтобы структура была понятна всем сторонам, работающим на подуровне сервиса DetNet. Работа метода подробно описана в [DetNet-MPLS].

3.5. Другие вопросы плоскости данных DetNet

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

3.5.1. Функции, обеспечиваемые на уровне потока

На верхнем уровне обеспечиваются на уровне потока описанные ниже функции.

3.5.1.1. Резервирование и выделение ресурсов

Ресурсы могут резервироваться, чтобы быть доступными для выделения конкретным потокам DetNet. Это может предотвратить «соперничество» и потери пакетов для трафика DetNet, а также снизить вариации задержки (jitter). Ресурсы, выделенные потоку DetNet, защищают его от других потоков трафика. С другой стороны предполагается, что потоки DetNet ведут себя в соответствии с зарезервированным профилем трафика. Должна обеспечиваться возможность обнаружения некорректного поведения потоков DetNet и предотвращения нарушений ими требований QoS других потоков. Очереди, правила и формовка трафика могут служить для распределения ресурсов, резервируемых DetNet.

3.5.1.2. Явные маршруты

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

3.5.1.3. Защита сервиса

Защита сервиса предполагает использование множества потоков пакетов с передачей по множеству путей, например, 1+1 или линейная защита 1:1. Для DetNet это связано в основном с возможностями репликации и исключения пакетов. MPLS обеспечивает множество схем защиты. Безотказную защиту MPLS можно применять для переключения трафика на уже созданный путь с целью быстрого восстановления доставки после отказа. Смена путей даже при восстановлении после отказа может приводить к нарушению порядка пакетов, что требует реализации POF на уровне сервиса DetNet или вышележащем уровне прикладного трафика. Организация новых путей при отказе выходит за рамки услуг DetNet.

3.5.1.4. Сетевое кодирование

Сетевое кодирование (Network Coding) [nwcrg], которое не следует путать с сетевым программированием, включает несколько методов для кодирования множества потоков данных. Получаемые в результате потоки можно передавать по разным путям. Операция кодирования может объединять поток с данными для восстановления ошибок. При декодировании и рекомбинации могут восстанавливаться исходные потоки. Отметим, что сетевое кодирование использует альтернативу попакетному применению PREOF. Поэтому для некоторых вариантов топологии и трафика сетевое кодирование позволяет повысить пропускную способность сети и улучшить параметры эффективности, задержки и расширяемости, а также повысить устойчивость к разделению, атакам и перехвату пакетов по сравнению с традиционными методами. DetNet может приментяь Network Coding в качестве дополнения к другим средствам защиты. Сетевое кодирование часто применяется в беспроводных сетях и исследуется для других типов сетей.

3.5.1.5. Распределение нагрузки

Использование попакетного (packet-by-packet) распределения нагрузки одного потока DetNet по множеству путей не рекомендуется, за исключением указанных выше случаев, где применяется PREOF для улучшения защиты и сохранения порядка. Попакетное распределение нагрузки, например, по равноценным (Equal-Cost Multipath или ECMP) или неравноценным (Unequal-Cost Multipath или UCMP) путям влияет на порядок и может влиять на вариации задержки.

3.5.1.6. Поиск неисправностей

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

3.5.1.7. Распознавание потоков для анализа

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

3.5.1.8. Сопоставление событий с потоками

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

3.5.2. Защита сервиса

Защита сервиса позволяет повысить отказоустойчивость служб DetNet и поддерживать желаемый уровень гарантий в случаях перегрузки или отказов в сети. DetNet опирается в схемах защиты на возможности используемых базовых технологий. Схемы защиты включают полное или частичное покрытие путей через сеть и активную защиту с использованием комбинаций PRF, PEF и POF.

3.5.2.1. Линейная защита сервиса

На рисунке 3 показан фрагмент сети DetNet MPLS и поток пакетов. Номера на рисунке указывают экземпляры пакета. Пакет 1 является исходным, 1.1 и 1.2 – первые копии исходного пакета, 1.2.1 – копия пакета 1.2 и т. д. Отметим, что эти номера не присутствуют в пакетах и их не следует путать с порядковыми номерами, метками или иными идентификаторами из пакетов. Они приведены здесь лишь для удобства ссылок.

   1      1.1       1.1      1.2.1    1.2.1      1.2.2
CE1----EN1--------R1-------R2-------R3--------EN2-----CE2
         \           1.2.1 /                  /
          \1.2     /------+                  /
           +------R4------------------------+
                     1.2.2

Рисунок 3. Пример потока пакетов, защищенного DetNet.


Пользовательское устройство CE1 передает пакет в сеть с поддержкой DetNet (пакет 1). Краевой узел EN1 инкапсулирует пакет как пакет DetNet и передает его ретранслятору R1 (1.1). EN1 также делает копию пакета (1.2), инкапсулирует ее и передает ретранслятору R4.

Отметим, что ретранслятор R1 может быть подключен к EN1 напрямую или через несколько узлов, которые для простоты на рисунке не показаны. То же можно сказать и о других путях между любыми двумя элементами DetNet.

Ретранслятор R4 можно настроить на отправку одной копии пакета (1.2.1) ретранслятору R2, а другой (1.2.2) – конечному узлу EN2.

R2 получает копию 1.2.1 до прихода копии 1.1 и, поскольку на нем настроено исключение дубликатов для этого потока DetNet, пересылает 1.2.1 ретранслятору R3. Копия 1.1 больше не используется и будет отброшена R2.

Краевой узел EN2 получает копию 1.2.2 от R4 до прихода копии 1.2.1 от R2 через ретранслятор R3. Поэтому EN2 вырезает инкапсуляцию DetNet из копии 1.2.2 и передает пакет CE2. Когда EN2 получает копию 1.2.1, она уже не нужна и отбрасывается.

Для приведенного выше примера можно настроить и другие сценарии.

Пример также иллюстрирует схему защиты 1:1, означающую наличие трафика через каждый сегмент сквозного пути. Локальные ретрансляторы DetNet определяют, какие пакеты нужно переслать, а какие исключить. Схема 1+1, где для трафика в каждый момент применяется лишь один путь, может использовать такую же топологию. В этом случае не будет применяться PRF, а при возникновении отказа произойдет переключение трафика с использованием схемы OAM, отслеживающей отказы. Функция POF может по-прежнему использоваться в этом случае для предотвращения нарушений порядка пакетов. В обоих случаях защитные пути организуются и поддерживаются в течение всего срока работы сервиса DetNet.

3.5.2.2. Дифференциальная зедержка между путями

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

3.5.2.3. Защита кольца

Защита кольца может обеспечиваться при ее поддержке базовой технологией. Используется много одинаковых концепций, однако в кольцах обычно применяют защиту 1+1 для обеспечения эффективности обмена данными. В [RFC8227] представлен пример плоскости данных транспортного профиля MPLS (MPLS Transport Profile или MPLS-TP) с поддержкой защиты кольца.

3.5.3. Вопросы агрегирования

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

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

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

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

3.5.3.1. Агрегирование IP

Агрегирование IP включает аспекты плоскостей управления и контроллера. Для плоскости управления потоки могут агрегироваться с целью обработки на основе общих характеристик, таких как 6-tuple [RFC8939]. Дополнительно может применяться инкапсуляция IP для туннелирования агрегата потоков DetNet между ретрансляторами.

3.5.3.2. Агрегирование MPLS

Агрегирование MPLS также включает аспекты плоскостей управления и контроллера. Потоки MPLS часто туннелируются на подуровне пересылки с резервированием, связанным с туннелем MPLS.

3.5.4. Конечные системы

Потоки данных, которым нужен сервис DetNet, создаются и завершаются в конечных системах. Инкапсуляция зависит от приложения и его предпочтений. Например, в домене DetNet MPLS функции подуровня используют d-CW, S-Label и F-Label [DetNet-MPLS] для предоставления услуг DetNet. Однако приложения могут обмениваться параметрами, связанными с потоками (например, временными метками), которые не предоставляются функциями DetNet.

+-----+
|  X  |                               +-----+
+-----+                               |  X  |
| Eth |               ________        +-----+
+-----+     _____    /        \       | Eth |
       \   /     \__/          \___   +-----+
        \ /                        \ /
         0======== tunnel-1 ========0_
         |                             \
          \                             |
          0========= tunnel-2 =========0
         / \                        __/ \
  +-----+   \__ Домен DetNet MPLS  /     \
  |  X  |      \         __       /       +-----+
  +-----+       \_______/  \_____/        |  X  |
  |  IP |                                 +-----+
  +-----+                                 |  IP |
                                          +-----+

Рисунок 4. Конечные системы и домен DetNet MPLS.


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

3.5.5. Подсети

                   +------+  +------+  +------+
App-flow           |  X   |  |  X   |  |  X   |
             +-----+======+--+======+--+======+-----+
DetNet-MPLS        | d-CW |  | d-CW |  | d-CW |
                   +------+  +------+  +------+
                   |Метки |  |Метки |  |Метки |
             +-----+======+--+======+--+======+-----+
Подсеть            |  L2  |  | TSN  |  | UDP  |
                   +------+  +------+  +------+
                                       |  IP  |
                                       +------+
                                       |  L2  |
                                       +------+

Рисунок 5. Пример инкапсуляции DetNet MPLS в подсетях.


Услуги DetNet любого типа могут предоставляться с использованием другого сервиса DetNet. Узлы MPLS могут быть соединены через подсети с иной технологией, которые могут включать каналы «точка-точка». Каждая из технологий подсетей должна предоставлять услуги, подходящие для потоков DetNet. В некоторых случаях (например, на выделенных каналах «точка-точка» или при использовании технологии TDM) от узла DetNet требуется лишь подходящая организация очередей для трафика. В иных случаях узлы DetNet должны отображать потоки DetNet на семантику (например, идентификаторы) и механизмы, используемые базовой технологией подсети. На рисунке 5 показано несколько примеров инкапсуляции в подсетях, которая может применяться для передачи потоков DetNet MPLS с использованием других технологий. L2 представляет базовую инкапсуляцию канального уровня, которая может применяться в соединениях «точка-точка». TSN указывает инкапсуляцию IEEE 802.1 TSN [DetNet-MPLS-over-TSN], а UDP/IP – инкапсуляцию DetNet IP PSN [DetNet-MPLS-over-UDP-IP].

4. Плоскость контроллера (поддержка и управление)

4.1. Требования плоскости контроллера DetNet

Плоскость контроллера (Controller Plane) соответствует объединению плоскостей управления и администрирования (Control и Management), описанному в [RFC7426] и [RFC8655]. Подробное рассмотрение плоскости контроллера DetNet выходит за рамки этого документа, однако ниже обсуждаются некоторые вопросы и требования к Controller Plane, связанные с уникальными характеристиками архитектуры DetNet и определенной здесь плоскости данных.

Основные требования к возможностям плоскости контроллера DetNet приведены ниже.

  • Создание экземпляров потоков DetNet в домене DetNet (который может, например, включать определение явных путей, резервирование пропускной способности, ограничение потоков в каналы IEEE 802.1 TSN, буферы узлов и другое резервирование ресурсов, спецификация требуемых в пути очередей, возможность управления двухсторонними потоками и т. п.) по мере потребности в потоках.

  • В случае MPLS управление выделением и распространением меток DetNet S-Label и F-Label. Использование инкапсуляции DetNet MPLS описано в [DetNet-MPLS].

  • Поддержка агрегирования потоков DetNet.

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

  • Расширение для обработки ожидаемого в домене числа потоков DetNet, для чего может потребоваться сигнализация или обеспечение на уровне потока.

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

Эти требования, как отмечено выше, могут быть выполнены с помощью распределенного сигнального протокола управления (например, RSVP-TE), механизмов централизованного управления сетью (BGP, PCEP, YANG, [DetNet-Flow-Info] и т. п.) или их комбинации, а также можно применять сегментную маршрутизацию на основе MPLS.

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

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

4.2. Базовая плоскость контроллера

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

Хотя плоскости администрирования и управления обычно рассматривают отдельно, с точки зрения плоскости данных нет практических различий, основанных на источнике информации о предоставлении потоков и в архитектуре DetNet [RFC8655] администрирование и управление отнесены к единой плоскости контроллера (Controller Plane). Поэтому документ не разделяет информацию от распределенных протоколов плоскости управления (например, RSVP-TE [RFC3209] [RFC3473]) и централизованных механизмов управления сетью (например, RESTCONF [RFC8040], YANG [RFC7950], PCEP [PCECC]) или их комбинации. Конкретные вопросы и требования к плоскости контроллера DetNet рассмотрены в разделе 4.1. Требования плоскости контроллера DetNet.

В каждом документе плоскости данных рассматриваются также вопросы плоскости управления для соответствующей технологии. Например, в [RFC8939] охватываются также нормативные аспекты плоскости управления для IP, а в [DetNet-MPLS] – для MPLS.

4.2.1. Управление агрегированием потоков

Агрегирование потоков означает обслуживание множества App-flow одним потоком DetNet. Для агрегирования применяется множество методов, например, в случае IP потоки IP с общими атрибутами 6-tuple или идентификаторами подуровня DetNet можно сгруппировать. Другим примером служит агрегирование с использованием иерархических LSP в MPLS и туннелях.

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

Сбор и распространение сведений о ресурсах организации трафика

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

Расчет пути и выделение ресурсов

При предоставлении или запросе сервиса DetNet выбирается один или несколько путей с проверкой и записью соответствующих ресурсов.

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

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

Запись и обновление выделенных ресурсов

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

4.2.2. Явные маршруты

Явные маршруты применяются для гарантированной отправки пакетов по путям с зарезервированными ресурсами, чтобы обеспечить приложениям DetNet требуемое обслуживание. От плоскости контроллера DetNet требуется способность назначить конкретному идентифицированному потоку DetNet IP путь через домен DetNet, которому были выделены требуемые ресурсы на каждом узле. Это обеспечивает подобающую обработку трафика для потока, а также включает как часть пути конкретные каналы, способные поддержать поток DetNet. Например, параметры DetNet можно обеспечить за счет использования каналов IEEE 802.1 TSN [DetNet-MPLS-over-TSN]. Дополнительное рассмотрение требований к плоскости контроллера DetNet приведено в параграфе 4.1. Требования плоскости контроллера DetNet.

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

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

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

  • Путь может использовать распределенную плоскость управления, такую как RSVP [RFC2205] или RSVP-TE [RFC3473], с расширением для поддержки потоков DetNet IP.

  • Путь можно реализовать с использованием сегментной маршрутизации на основе IPv6, расширенной для поддержки выделения ресурсов.

Эти варианты рассмотрены в параграфе 4.1. Кроме того, в [RFC2386] приведены полезные сведения о маршрутизации на основе QoS, а в [RFC5575] (обновлен [Flow-Spec-Rules]) обсуждается конкретный механизм, используемый BGP для задания потоков трафика и маршрутизации на основе правил.

4.2.3. Потери из-за конкуренции и снижение вариаций задержки

Этот документ не задает механизмы, требуемые для предотвращения конкуренции и потери пакетов, а также ограничения вариаций задержки для потоков DetNet на подуровне пересылки DetNet. Способность управлять ресурсами узлов и каналов для обеспечения этих функций является необходимой частью плоскости контроллера DetNet. Необходима также возможность управления требуемыми механизмами очередей, используемыми для обеспечения этих функций на пути через сеть. Эти требования рассматриваются в [RFC8939] и разделе 4.1. Некоторые формы защиты могут минимизировать потерю пакетов или изменить характеристики вариаций задержки при нарушении порядка пакетов, когда такие пакеты получены подуровнем сервиса.

4.2.4. Двухсторонний трафик

Во многих случаях потоки DetNet можно считать односторонними и независимыми. Однако иногда сервис DetNet требует двухстороннего трафика с точки зрения приложений DetNet. В IP и MPLS обычно каждое направление обрабатывается самостоятельно и между встречными направлениями не возникает взаимной зависимости. Рабочая группа IETF MPLS изучила требования к двухстороннему трафику. Определения, представленные в [RFC5654], полезны для иллюстрации двухсторонних потоков, в том числе с общей маршрутизацией. MPLS определяет двухсторонний LSP, связанный с соединением «точка-точка», как два односторонних LSP «точка-точка» (от A к B и от B к A), которые рассматриваются как один логический двухсторонний путь. Это аналог стандартной маршрутизации IP. Двухсторонний LSP «точка-точка» с общей маршрутизацией определяется в MPLS как двухсторонний LSP, удовлетворяющий дополнительному требованию использовать в обоих направлениях один путь (один набор узлов и каналов). Важным свойством таких LSP является «общая судьба» путей в каждом направлении. Для обоих типов двухсторонних LSP резервирование в каждом из направления может быть разным. Концепции связанных двухсторонних потоков (в том числе с общей маршрутизацией) применимы и к потокам DetNet IP.

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

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

Механизмы управления и администрирования должны поддерживать двухсторонние потоки, но спецификация таких механизмов выходит за рамки документа. Примеры решений для плоскости управления MPLS можно найти в [RFC3473], [RFC6387] и [RFC7551]. Эти требования включены в раздел 4.1. Требования плоскости контроллера DetNet.

4.3. Функции PREOF

Выбор протокола плоскости контроллера, требуемого для управления работой PREOF, выходит за рамки документа. Тем не менее, следует отметить, что явно требуется возможность определить для конкретного потока оптимальные точки репликации и исключения дубликатов в домене DetNet. Некоторые имеющиеся возможности можно применить или расширить для решения этой задачи, например, сквозное восстановление GMPLS [RFC4872] и восстановление сегментов GMPLS [RFC4873].

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

Вопросы безопасности DetNet подробно рассматриваются в [DetNet-Security], а базовые проблемы безопасности для архитектуры DetNet – в [RFC8655]. В этом разделе обсуждаются вопросы безопасности на уровне архитектуры DetNet, применимые ко всем плоскостям данных.

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

Для всех коммуникационных протоколов первоочередной задачей плоскости данных является обеспечение целостности данных и предоставление услуг DetNet через сеть DetNet. Потоки приложений можно защитить любыми способами, предоставляемыми базовой технологией. Например, может применяться шифрование, подобное используемому в IPsec [RFC4301] для потоков IP или MACsec [IEEE802.1AE-2018] для потоков Ethernet (L2).

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

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

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

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

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

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

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

[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, “Deterministic Networking Architecture”, RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.

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

[DetNet-Flow-Info] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, “DetNet Flow Information Model”, Work in Progress, Internet-Draft, draft-ietf-detnet-flow-information-model-11, 21 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-11>.

[DetNet-MPLS] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, “DetNet Data Plane: MPLS”, Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-13, 11 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-13>.

[DetNet-MPLS-over-TSN] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, “DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)”, Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-over-tsn-04, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-tsn-04>.

[DetNet-MPLS-over-UDP-IP] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, “DetNet Data Plane: MPLS over UDP/IP”, Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-over-udp-ip-07, 11 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-udp-ip-07>.

[DetNet-Security] Grossman, E., Ed., Mizrahi, T., and A. Hacker, “Deterministic Networking (DetNet) Security Considerations”, Work in Progress, Internet-Draft, draft-ietf-detnet-security-12, 2 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-security-12>.

[Flow-Spec-Rules] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, “Dissemination of Flow Specification Rules”, Work in Progress, Internet-Draft, draft-ietf-idr-rfc5575bis-27, 15 October 2020, <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-27>.

[IEEE802.1AE-2018] IEEE, “IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security”, IEEE Std 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December 2018, <https://ieeexplore.ieee.org/document/8585421>.

[IEEE802.1TSNTG] IEEE, “Time-Sensitive Networking (TSN) Task Group”, <https://1.ieee802.org/tsn/>.

[nwcrg] IRTF, “Coding for efficient NetWork Communications Research Group (nwcrg)”, <https://datatracker.ietf.org/rg/nwcrg/about>.

[PCECC] Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, “PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs”, Work in Progress, Internet-Draft, draft-ietf-pce-pcep-extension-for-pce-controller-08, 1 November 2020, <https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controller-08>.

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification”, RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.

[RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, “A Framework for QoS-based Routing in the Internet”, RFC 2386, DOI 10.17487/RFC2386, August 1998, <https://www.rfc-editor.org/info/rfc2386>.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels”, RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.

[RFC3473] Berger, L., Ed., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions”, RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.

[RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, “Information Model for Describing Network Device QoS Datapath Mechanisms”, RFC 3670, DOI 10.17487/RFC3670, January 2004, <https://www.rfc-editor.org/info/rfc3670>.

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., “RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery”, RFC 4872, DOI 10.17487/RFC4872, May 2007, <https://www.rfc-editor.org/info/rfc4872>.

[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, “GMPLS Segment Recovery”, RFC 4873, DOI 10.17487/RFC4873, May 2007, <https://www.rfc-editor.org/info/rfc4873>.

[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, “Dissemination of Flow Specification Rules”, RFC 5575, DOI 10.17487/RFC5575, August 2009, <https://www.rfc-editor.org/info/rfc5575>.

[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile”, RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>.

[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, “GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)”, RFC 6387, DOI 10.17487/RFC6387, September 2011, <https://www.rfc-editor.org/info/rfc6387>.

[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, “Software-Defined Networking (SDN): Layers and Architecture Terminology”, RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.

[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., “RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)”, RFC 7551, DOI 10.17487/RFC7551, May 2015, <https://www.rfc-editor.org/info/rfc7551>.

[RFC7657] Black, D., Ed. and P. Jones, “Differentiated Services (Diffserv) and Real-Time Communication”, RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. Dong, “MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology”, RFC 8227, DOI 10.17487/RFC8227, August 2017, <https://www.rfc-editor.org/info/rfc8227>.

[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, “Deterministic Networking (DetNet) Data Plane: IP”, RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.

[SRv6-Network-Prog] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, “SRv6 Network Programming”, Work in Progress, Internet-Draft, draft-ietf-spring-srv6-network-programming-26, 26 November 2020, <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-26>.

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

Авторы благодарят Pat Thaler, Norman Finn, Loa Andersson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Carlos J. Bernardos за их вклад в работу.

Участники работы

Существенный вклад в создание этого документа внесли Don Fedyk и Jouni Korhonen

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

Balázs Varga (editor)

Ericsson

Budapest

Magyar Tudosok krt. 11.

1117

Hungary

Email: balazs.a.varga@ericsson.com

János Farkas

Ericsson

Budapest

Magyar Tudosok krt. 11.

1117

Hungary

Email: janos.farkas@ericsson.com

Lou Berger

LabN Consulting, L.L.C.

Email: lberger@labn.net

Andrew G. Malis

Malis Consulting

Email: agmalis@gmail.com

Stewart Bryant

Futurewei Technologies

Email: sb@stewartbryant.com

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

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

nmalykh@protocols.ru

1Deterministic Networking.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Operations, Administration, and Maintenance – операции, администрирование и поддержка.

5Man-in-the-middle – «человек в середине».

Рубрика: RFC | Комментарии к записи RFC 8938 Deterministic Networking (DetNet) Data Plane Framework отключены

RFC 8922 A Survey of the Interaction between Security Protocols and Transport Services

image_print
Internet Engineering Task Force (IETF)                       T. Enghardt
Request for Comments: 8922                                     TU Berlin
Category: Informational                                         T. Pauly
ISSN: 2070-1721                                               Apple Inc.
                                                              C. Perkins
                                                   University of Glasgow
                                                                 K. Rose
                                               Akamai Technologies, Inc.
                                                                 C. Wood
                                                              Cloudflare
                                                            October 2020

A Survey of the Interaction between Security Protocols and Transport Services

Обзор взаимодействия между протоколами защиты и транспортными службами

PDF

Аннотация

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

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

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

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

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

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

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

Услуги и свойства, предоставляемые транспортными протоколами, классифицированы в [RFC8095]. Это документ дополняет выполненную работу и указывает интерфейсы между этими протоколами, а также между транспортными протоколами и приложениями. Документ исследует TLS3, DTLS4, IETF QUIC, Google QUIC (gQUIC), tcpcrypt, IPsec5, SRTP6 с DTLS, WireGuard, CurveCP, MinimaLT и для каждого протокола в документе приведено краткое описание. Описаны также интерфейсы между этими протоколами и транспортом (раздел 4) и интерфейсы между протоколами и приложениями (раздел 5).

Система транспортных служб раскрывает приложениям интерфейс для доступа к разным (защищенным) транспортным функциям. Протоколы защиты, включенные в этот исследование, представляют расширенный набор функций и возможностей транспортных служб, которые могут потребоваться приложениям как для внутреннего, так и для внешнего применения (через API) [TAPS-ARCH]. Распространенные повсеместно протоколы IETF, такие как (D)TLS, наряду с нестандартными протоколами (например, gQUIC) включены в документ, несмотря на перекрывающиеся функции. Таким образом, исследование не ограничивается протоколами разработанными в сфере действия или контексте IETF. За пределами этого набора остались протоколы, которые не предлагают новых функций. Например, более новые протоколы, такие как WireGuard, применяют уникальные решения, которые могут влиять на ограничения при использовании приложений. Напротив, такие протоколы, как SSH [RFC4253], GRE [RFC2890], L2TP7 [RFC5641], ALTS8 [ALTS] не включены в обзор, поскольку они не имеют уникальных интерфейсов.

Не включены протоколы, предлагающие лишь аутентификацию, такие как TCP-AO9 [RFC5925] и IPsec AH10 [RFC4302]. TCP-AO добавляет аутентификацию для долгосрочных соединений TCP, например, защиту от повторного использования пакетов с помощью кодов MAC11 на уровне сообщения. TCP-AO обменяет «подписи» TCP MD5, заданные в [RFC2385] и одним из основных применений TCP-AO является защита соединений BGP. AH добавляет на уровне дейтаграмм аутентификацию и защиту целостности, а также защиту от повтора пакетов. Несмотря на эти усовершенствования, ни один из протоколов не относится в категории общего пользования и оба не включают важных свойств, требуемых для новых протоколов защиты, таких как защита конфиденциальности и приватности. Такие протоколы не включены в исследование.

В документ включены лишь протоколы парного взаимодействия (point-to-point), но не групповые протоколы.

1.1. Цели

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

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

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

1.2. Дополнительные аспекты

Хотя анализ в этом документе похож на анализ транспортных протоколов в [RFC8095], важно подчеркнуть, что применение протоколов защиты требует большего внимания.

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

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

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

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

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

Ниже приведены определения используемых в документе терминов для описания ролей и взаимодействий протоколов защищенного транспорта (некоторые термины определены также в [RFC8095]).

Transport Feature – транспортная функция (свойство)

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

Transport Service – транспортный сервис (служба)

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

Transport Services system – система транспортных услуг

Программные компоненты, раскрывающие приложению интерфейс к разным транспортным службам.

Transport Protocol – транспортный протокол

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

Application – приложение

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

Security Protocol – протокол защиты (безопасности)

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

Handshake Protocol – протокол согласования

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

Record – запись

Кадрированные сообщения протокола.

Record Protocol – протокол записей

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

Session – сессия (сеанс)

Эфемерная защитная ассоциация между приложениями.

Connection – соединение

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

Peer – партнер

Приложение конечной точки, участвующее в сессии.

Client – клиент

Партнер, отвечающий за инициирование сессии.

Server – сервер

Партнер, отвечающий за отклик на инициирование сессии.

3. Описания протоколов транспортной защиты

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

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

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

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

Для некоторых протоколов (например, tcpcrypt) эти компоненты тесно связаны. И напротив, в IPsec они реализованы в разных протоколах – AH и ESP12, – являющихся протоколами записи, которые используют ключи, предоставленные протоколом обмена ключами IKEv213, другими протоколами согласования или вручную.

Кроме того, некоторые протоколы могут использоваться разными способами. Базовый протокол TLS, определенный в [RFC8446], имеет встроенные протоколы согласования и записей, но TLS или DTLS можно также применять для согласования ключей в других протоколах (например, DTLS-SRTP) или протокол согласования может использоваться с отдельным уровнем записей, как в QUIC [QUIC-TRANSPORT].

3.1. Протоколы защиты данных приложения

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

3.1.1. TLS

TLS [RFC8446] является базовым протоколом для организации защищенных сессий между парой конечных точек. Коммуникации в таких сессиях защищены от перехвата, подмены и подставных сообщений. TLS включает тесно связанные протоколы согласования и записей. Протокол согласования служит для аутентификации партнеров, согласования опций протокола, таких как криптографические алгоритмы, и создания ключевого материала для сессии. Протокол записей используется для «присмотра» (marshal), а после согласования служит для шифрования данных между партнерами. Эти данные могут включать согласующие сообщения и необработанные (raw) данные приложения.

3.1.2. DTLS

Протокол DTLS [RFC6347] [DTLS-1.3] основан на TLS, но отличается тем, что предназначен для работы с протоколами дейтаграмм, такими как UDP, взамен TCP. DTLS меняет протокол, чтобы обеспечить гарантии защиты, эквивалентные TLS, за исключением сохранения порядка и невозможности повторного использования. DTLS разработан максимально похожим на TLS, поэтому здесь предполагается, что перенесены все свойства TLS, кроме отмеченных выше.

3.2. Зависимые от приложения протоколы защиты

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

3.2.1. Secure RTP

Secure RTP (SRTP) – это профиль RTP, обеспечивающий конфиденциальность, аутентификацию сообщений и защиту от повторного использования для пакетов данных RTP и пакетов протокола управления RTCP14 [RFC3711]. SRTP поддерживать только уровень записей и требует отдельного протокола согласования для управления ключами и контроля идентичности.

Наиболее широко в качестве протокола согласования для SRTP применяется DTLS в форме DTLS-SRTP [RFC5764]. Это расширение DTLS, согласующее применение SRTP как уровня записей и описывающее экспорт ключей для SRTP.

ZRTP [RFC6189] является другим вариантом протокола согласования ключей и контроля идентичности для SRTP. Согласование ключей в ZRTP выполняется с использованием обмена Diffie-Hellman на пути в среде. Алгоритм создает общий ключ, который служит для генерации первичного ключа и затравки (salt) для SRTP.

3.3. Протоколы защиты на транспортном уровне

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

3.3.1. IETF QUIC

QUIC — это новый стандартный протокол, работающий по протоколу UDP и частично основанный на фирменном протоколе Google (gQUIC) [QUIC-TRANSPORT] (см. параграф 3.3.2). Транспортный уровень QUIC обеспечивает защиту конфиденциальности и целостности. Это требует создания ключей с помощью отдельного протокола согласования. Отображение QUIC на TLS 1.3 [QUIC-TLS] была задано для выполнения такого согласования.

3.3.2. Google QUIC

Google QUIC (gQUIC) – это основанный на UDP мультиплексируемый потоковый протокол, разработанный и размернутый компанией Google на основании опыта развертывания SPDY – фирменного предшественника HTTP/2. Протокол gQUIC исходно назывался QUIC, но в этом документе используется обозначение gQUIC, чтобы различать этот протокол и IETF QUIC. Запатентованный технический предшественник IETF QUIC – gQUIC исходно включает интеграцию защиты и транспорта данных приложений.

3.3.3. tcpcrypt

Протокол tcpcrypt [RFC8548] является облегченным расширением TCP для гибкого управления шифрованием. Приложения могут использовать уникальные идентификаторы сессий tcpcrypt для дополнительной аутентификации на уровне приложений. Без этой аутентификации протокол tcpcrypt уязвим для активных атак.

3.3.4. MinimaLT

MinimaLT [MinimaLT] – это основанный на UDP протокол транспортной защиты, разработанный для обеспечения конфиденциальности, взаимной аутентификации, предотвращения DoS15 и мобильности соединений. Одной из основных целей протокола является усиление имеющихся протоколов для получения данных конфигурации на стороне сервера, используемых для ускоренной организации соединения. MinimaLT использует вариант механизма контроля перегрузок TCP.

3.3.5. CurveCP

CurveCP [CurveCP] – это основанный на UDP протокол транспортной защиты, основанный в отличие от многих других протоколов защиты, полностью на алгоритмах открытых ключей. CurveCP обеспечивает гарантии для данных приложения как часть протокола.

3.4. Протоколы защиты пакетов

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

3.4.1. IPsec

IKEv2 [RFC7296] и ESP [RFC4303] совместно образуют современный стек протоколов IPsec для шифрования и аутентификации пакетов IP при создании туннелей (туннельный режим) или непосредственно в транспортных соединениях (транспортный режим). Этот стек протоколов отделяет протокол генерации ключей (IKEv2) от протокола транспортного шифрования (ESP). Каждый протокол можно применять независимо, но в этом документе они рассматриваются вместе, поскольку это встречается чаще.

3.4.2. WireGuard

WireGuard [WireGuard] – это протокол уровня IP, разработанный как альтернатива IPsec для некоторых вариантов применения. Протокол использует UDP для инкапсуляции дейтаграмм IP между партнерами. В отличии от большинства протоколов транспортной защиты, опирающихся на PKI17 для аутентификации партнера, WireGuard проверяет подлинность партнеров с помощью заранее распространенных открытых ключей, переданных по отдельному каналу (out of band), каждый из которых привязан к одному или множеству адресов IP. Кроме того, как протокол, предназначенный для VPN, WireGuard не предлагает расширяемости, согласования и криптографической ловкости (agility).

3.4.3. OpenVPN

OpenVPN [OpenVPN] – это широко распространенный протокол, разработанный как альтернатива IPsec. Основной целью протокола является организация VPN с простой настройкой и работой с разным транспортом. OpenVPN инкапсулирует пакеты IP или кадры Ethernet в защищенный туннель и может работать по протоколу UDP или TCP. Для организации ключей OpenVPN может использовать TLS в качестве протокола согласования или работать с заранее распространенными ключами.

4. Транспортные зависимости

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

4.1. Надежный транспорт для байтовых потоков

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

Протоколы защиты данных приложения (payload)

TLS.

Протоколы защиты на транспортном уровне

tcpcrypt.

4.2. Транспортировка дейтаграмм без гарантий

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

Протоколы защиты данных приложения (payload)

DTLS;

ZRTP;

SRTP.

Протоколы защиты на транспортном уровне

QUIC;

MinimaLT;

CurveCP.

Протоколы защиты пакетов

IPsec;

WireGuard;

OpenVPN.

4.2.1. Протоколы дейтаграмм с отображением на поток байтов

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

Протоколы защиты данных приложения (payload)

DTLSпри использовании как протокола согласования для SRTP [RFC7850];

ZRTP [RFC6189];

SRTP [RFC4571][RFC3711].

Протоколы защиты пакетов

IPsec [RFC8229].

4.3. Связанные с транспортом зависимости

Один из рассматриваемых протоколов (tcpcrypt) имеет прямую зависимость от свойства транспорта, требуемого для его работы. А именно, tcpcrypt предназначен для работы на основе TCP и использует опцию TCP-ENO18 [RFC8547] для согласования поддержки протокола.

QUIC, CurveCP и MinimaLT поддерживают функции транспорта и защиты. Они зависят от работы по протоколу с кадрированием, подобному UDP, но добавляют свои уровни гарантий доставки и других транспортных услуг. Таким образом, приложение, использующее такой протокол, не может отвязать защиту от транспортной функциональности.

5. Интерфейс с приложениями

В этом разделе описаны интерфейсы, раскрываемые описанными выше протоколами защиты. Эти интерфейсы разделены на pre-connection (до соединения, настройка), connection (соединение), post-connection (после соединения) в соответствии с соглашениями [TAPS-INTERFACE] и [TAPS-ARCH].

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

5.1. Интерфейсы до соединения

Конфигурационные интерфейсы служат для настройки протоколов защиты до начала согласования или установки ключей.

Отождествления и секретные ключи (IPK19)

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

  • TLS;
  • DTLS;
  • ZRTP;
  • QUIC;
  • MinimaLT;
  • CurveCP;
  • IPsec;
  • WireGuard;
  • OpenVPN.

Поддерживаемые алгоритмы (обмен ключами, подписи, шифронаборы) (ALG)

Прложение может выбрать алгоритмы, поддерживаемые им для обмена ключами, подписями и шифронаборами.

  • TLS;
  • DTLS;
  • ZRTP;
  • QUIC;
  • tcpcrypt;
  • MinimaLT;
  • IPsec;
  • OpenVPN.

Расширения (EXT)

Приложение включает или настраивает расширения, согласуемые протоколом защиты, таким как ALPN20 [RFC7301].

  • TLS;
  • DTLS;
  • QUIC.

Управление сеансовым кэшем (CM21)

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

  • TLS;
  • DTLS;
  • ZRTP;
  • QUIC;
  • tcpcrypt;
  • MinimaLT.

Передача полномочий проверки подлинности (AD22)

Приложение предоставляет доступ к отдельному модулю, обеспечивающему аутентификацию, например, с помощью протокола EAP23 [RFC3748].

  • IPsec;
  • tcpcrypt.

Импорт заранее распространенных ключей (PSKI24)

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

  • TLS;
  • DTLS;
  • ZRTP;
  • QUIC;
  • tcpcrypt;
  • MinimaLT;
  • IPsec;
  • WireGuard;
  • OpenVPN.

5.2. Интерфейсы соединения

Проверка идентичности (IV25)

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

  • TLS;
  • DTLS;
  • ZRTP;
  • QUIC;
  • MinimaLT;
  • CurveCP;
  • IPsec;
  • WireGuard;
  • OpenVPN.

Проверка адреса получателя (SAV26)

Протокол согласования может взаимодействовать с транспортных протоколом или приложением для проверки адреса удаленного партнера, приславшего данные. Это включает обмен cookie для предотвращения DoS-атак. В списке не указаны протоколы, зависящие от TCP, что ведет к неявному выполнению SAV.

  • DTLS;
  • QUIC;
  • IPsec;
  • WireGuard.

5.3. Интерфейсы после соединения

Прерывание соединения (CT27)

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

  • TLS;
  • DTLS;
  • ZRTP;
  • QUIC;
  • tcpcrypt;
  • MinimaLT;
  • IPsec;
  • OpenVPN.

Обновление ключей (KU28)

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

  • TLS;
  • DTLS;
  • QUIC;
  • tcpcrypt;
  • MinimaLT;
  • IPsec.

Экспорт общего секретного ключа (SSKE29)

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

  • TLS;
  • DTLS;
  • tcpcrypt;
  • IPsec;
  • OpenVPN;
  • MinimaLT.

Завершение срока действия ключа (KE30)

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

  • IPsec.

События мобильности (ME31)

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

  • DTLS (только версия 1.3 [DTLS-1.3]);
  • QUIC;
  • MinimaLT;
  • CurveCP;
  • IPsec [RFC4555];
  • WireGuard.

5.4. Сводка интерфейсов, раскрываемых протоколами

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

Таблица 1.

Протокол

IPK

ALG

EXT

CM

AD

PSKI

IV

SAV

CT

KU

SSKE

KE

ME

TLS

+

+

+

+

+

+

+

+

+

DTLS

+

+

+

+

+

+

+

+

+

+

+

ZRTP

+

+

+

+

+

+

QUIC

+

+

+

+

+

+

+

+

+

+

tcpcrypt

+

+

+

+

+

+

+

MinimaLT

+

+

+

+

+

+

+

+

+

CurveCP

+

+

+

IPsec

+

+

+

+

+

+

+

+

+

+

+

WireGuard

+

+

+

+

+

OpenVPN

+

+

+

+

+

+

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

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

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

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

8. Вопросы приватности

Анализ влияния функций на снижение или рост защиты приватности намеренно не включен в документ. Все рассмотренные протоколы защиты в целом повышают уровень приватности за счет шифрования для снижения утечек информации. Однако то или иное количество метаданных сохраняется каждым протоколом в открытом виде. Например, сертификаты клиентов и серверов передаются в открытом виде для TLS 1.2 [RFC5246], но шифруются в TLS 1.3 [RFC8446]. Обзор свойств приватности или их отсутствия может быть дан в отдельномдокументе.

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

[ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, B., and J. Boeuf, “Application Layer Transport Security”, <https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/>.

[CurveCP] Bernstein, D., “CurveCP: Usable security for the Internet”, <https://curvecp.org/>.

[DTLS-1.3] Rescorla, E., Tschofenig, H., and N. Modadugu, “The Datagram Transport Layer Security (DTLS) Protocol Version 1.3”, Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-38, 29 May 2020, <https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>.

[MinimaLT] Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and T. Lange, “MinimaLT: minimal-latency networking through better security”, DOI 10.1145/2508859.2516737, <https://dl.acm.org/citation.cfm?id=2516737>.

[OpenVPN] OpenVPN, “OpenVPN cryptographic layer”, <https://openvpn.net/community-resources/openvpn-cryptographic-layer/>.

[QUIC-TLS] Thomson, M. and S. Turner, “Using TLS to Secure QUIC”, Work in Progress, Internet-Draft, draft-ietf-quic-tls-31, 24 September 2020, <https://tools.ietf.org/html/draft-ietf-quic-tls-31>.

[QUIC-TRANSPORT] Iyengar, J. and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport”, Work in Progress, Internet-Draft, draft-ietf-quic-transport-31, 24 September 2020, <https://tools.ietf.org/html/draft-ietf-quic-transport-31>.

[RFC2385] Heffernan, A., “Protection of BGP Sessions via the TCP MD5 Signature Option”, RFC 2385, DOI 10.17487/RFC2385, August 1998, <https://www.rfc-editor.org/info/rfc2385>.

[RFC2890] Dommety, G., “Key and Sequence Number Extensions to GRE”, RFC 2890, DOI 10.17487/RFC2890, September 2000, <https://www.rfc-editor.org/info/rfc2890>.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP)”, RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., “Extensible Authentication Protocol (EAP)”, RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.

[RFC4253] Ylonen, T. and C. Lonvick, Ed., “The Secure Shell (SSH) Transport Layer Protocol”, RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.

[RFC4302] Kent, S., “IP Authentication Header”, RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>. [RFC4303] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC4555] Eronen, P., “IKEv2 Mobility and Multihoming Protocol (MOBIKE)”, RFC 4555, DOI 10.17487/RFC4555, June 2006, <https://www.rfc-editor.org/info/rfc4555>.

[RFC4571] Lazzaro, J., “Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport”, RFC 4571, DOI 10.17487/RFC4571, July 2006, <https://www.rfc-editor.org/info/rfc4571>.

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

[RFC5641] McGill, N. and C. Pignataro, “Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values”, RFC 5641, DOI 10.17487/RFC5641, August 2009, <https://www.rfc-editor.org/info/rfc5641>.

[RFC5764] McGrew, D. and E. Rescorla, “Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)”, RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, “The TCP Authentication Option”, RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, “ZRTP: Media Path Key Agreement for Unicast Secure RTP”, RFC 6189, DOI 10.17487/RFC6189, April 2011, <https://www.rfc-editor.org/info/rfc6189>.

[RFC6347] Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security Version 1.2”, RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, “Internet Key Exchange Protocol Version 2 (IKEv2)”, STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[RFC7850] Nandakumar, S., “Registering Values of the SDP ‘proto’ Field for Transporting RTP Media over TCP under Various RTP Profiles”, RFC 7850, DOI 10.17487/RFC7850, April 2016, <https://www.rfc-editor.org/info/rfc7850>.

[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., “Services Provided by IETF Transport Protocols and Congestion Control Mechanisms”, RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.

[RFC8229] Pauly, T., Touati, S., and R. Mantha, “TCP Encapsulation of IKE and IPsec Packets”, RFC 8229, DOI 10.17487/RFC8229, August 2017, <https://www.rfc-editor.org/info/rfc8229>.

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

[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. Smith, “TCP-ENO: Encryption Negotiation Option”, RFC 8547, DOI 10.17487/RFC8547, May 2019, <https://www.rfc-editor.org/info/rfc8547>.

[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, “Cryptographic Protection of TCP Streams (tcpcrypt)”, RFC 8548, DOI 10.17487/RFC8548, May 2019, <https://www.rfc-editor.org/info/rfc8548>.

[TAPS-ARCH] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Perkins, C., Tiesel, P. S., and C. A. Wood, “An Architecture for Transport Services”, Work in Progress, Internet-Draft, draft-ietf-taps-arch-08, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-taps-arch-08>.

[TAPS-INTERFACE] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., and T. Pauly, “An Abstract Application Layer Interface to Transport Services”, Work in Progress, Internet-Draft, draft-ietf-taps-interface-09, 27 July 2020, <https://tools.ietf.org/html/draft-ietf-taps-interface-09>.

[WireGuard] Donenfeld, J., “WireGuard: Next Generation Kernel Network Tunnel”, <https://www.wireguard.com/papers/wireguard.pdf>.

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

Авторы благодарны Bob Bradley, Frederic Jacobs, Mirja Kühlewind, Yannick Sierra, Brian Trammell, Magnus Westerlund за их вклад и отклики на этот документ.

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

Theresa Enghardt

TU Berlin

Marchstr. 23

10587 Berlin

Germany

Email: ietf@tenghardt.net

Tommy Pauly

Apple Inc.

One Apple Park Way

Cupertino, California 95014

United States of America

Email: tpauly@apple.com

Colin Perkins

University of Glasgow

School of Computing Science

Glasgow

G12 8QQ

United Kingdom

Email: csp@csperkins.org

Kyle Rose

Akamai Technologies, Inc.

150 Broadway

Cambridge, MA 02144

United States of America

Email: krose@krose.org

Christopher A. Wood

Cloudflare

101 Townsend St

San Francisco,

United States of America

Email: caw@heapingbits.net

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

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

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Transport Layer Security – защита транспортного уровня.

4Datagram Transport Layer Security – защита транспортного уровня для дейтаграмм.

5Internet Protocol Security – защита протокола IP.

6Secure Real-time Transport Protocol – защищенный транспортный протокол в реальном масштабе времени.

7Layer 2 Tunneling Protocol – протокол туннелирования на канальном уровне.

8Application Layer Transport Security – протокол защиты транспорта прикладного уровня.

9TCP Authentication Option – опция аутентификации TCP.

10Authentication Header – заголовок аутентификации.

11Message Authentication Code – код аутентификации сообщения.

12Encapsulating Security Payload – защищенные данные инкапсуляции.

13Internet Key Exchange Protocol Version 2 – протокол обмена ключами в Internet, версия 2.

14RTP control protocol – протокол управления RTP.

15Denial-of-Service – отказ в обслуживании. Прим. перев.

16Virtual Private Network – виртуальная частная сеть.

17Public Key Infrastructure – инфраструктура открытых ключей.

18TCP Encryption Negotiation Option – опция согласования шифрования TCP.

19Identities and Private Keys.

20Application-Layer Protocol Negotiation – протокол согласования на уровне приложений.

21Cache Management.

22Authentication Delegation

23Extensible Authentication Protocol – расширяемый протокол аутентификации.

24Pre-Shared Key Import.

25Identity Validation.

26Source Address Validation.

27Connection Termination.

28Key Update.

29Shared Secret Key Export.

30Key Expiration.

31Mobility Events.

Рубрика: RFC | Комментарии к записи RFC 8922 A Survey of the Interaction between Security Protocols and Transport Services отключены

RFC 8923 A Minimal Set of Transport Services for End Systems

image_print
Internet Engineering Task Force (IETF)                          M. Welzl
Request for Comments: 8923                                   S. Gjessing
Category: Informational                               University of Oslo
ISSN: 2070-1721                                             October 2020

A Minimal Set of Transport Services for End Systems

Минимальный набор транспортных служб для конечной системы

PDF

Аннотация

Этот документ рекомендует минимальный набор транспортных служб (Transport Service), поддерживаемых конечной системой, и дает рекомендации по выбору доступных механизмов и протоколов. Документ основан на наборе транспортных функций из RFC 8303.

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

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

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

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

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

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

В настоящее время набор транспортных служб, используемых большинством приложений, основан на TCP и UDP (и вышележащих протоколах на исх основе), что ограничивает для сетевого стека возможности использовать свойства других транспортных протоколов. Например, если протокол поддерживает доставку пакетов с нарушением порядка, а приложение предполагает упорядоченность потока байтов в сети, сетевой стек не сможет сразу же доставить сообщение, полученное с нарушением порядка, и это вступит в конфликт с базовым допущением приложения. Результатом этого станет неоправданная задержка из-за блокировки HOL3.

Раскрывая транспортные службы нескольких протоколов, транспортная система позволяет приложениям использовать эти службы без статической привязки к определенному транспортному протоколу. Первый шаг к разработке таких систем был предложен в [RFC8095], где было исследовано множество транспортных протоколов, а также в [RFC8303] и [RFC8304], указавших конкретные свойства транспорта, которые раскрываются приложениям протоколами TCP, Multipath TCP (MPTCP), UDP(-Lite), SCTP4, а также механизмом контроля перегрузок LEDBAT5. Механизм LEDBAT был включен в этот список единственным среди механизмов контроля перегрузок, поскольку предоставляемые им услуги существенно отличаются от других механизмов этого типа. Этот документ основан на упомянутых работах и использует принятую в них терминологию (приведена ниже). Поскольку рассматриваемые транспортные протоколы совместно охватывают широкий спектр транспортных функций, есть основания надеяться, что предлагаемый набор (о приведшие к его выбору рассуждения) будут применимы ко многим аспектам других транспортных протоколов, которые смогут использоваться в современных и будущих решениях.

Отделив приложения от транспортных протоколов, транспортная система обеспечивает иной уровень абстракции, нежели интерфейс сокетов Berkeley [POSIX]. Как и в языках программирования, повышение уровня абстракции обеспечивает большую свободу автоматизации под интерфейсом, но отнимает часть контроля у программиста приложений. Это компромисс, с которым сталкивается разработчик транспортной системы, и в данном документе приведены рекомендации для этого уровня абстракции. Некоторые транспортные свойства в настоящее время редко включаются в API, однако их нужно предлагать, иначе они никогда не будут использоваться. Другие транспортные функции предлагаются API описываемых здесь протоколов, но если их не раскрывать в API, это даст больше свободы при автоматизации использования протокола в транспортной системе. Представленный здесь минимальный набор является попыткой найти компромисс, который можно рекомендовать для реализации транспортных систем на основе функций, рассматриваемых в [RFC8303].

Современные приложения используют множество API. Хотя этот документ предназначен для включения в API, разработанный группой Transport Services (TAPS) [TAPS-INTERFACE], большинства наиболее важных транспортных функций, представленный здесь «минимальный набор» должен включаться во все сетевые API, для обеспечения возможности использовать базовую функциональность. Например, это может не помочь приложению, взаимодействующему с библиотекой, которая обеспечивает свой коммуникационный интерфейс, если базовый Berkeley Sockets API расширен для поддержки неупорядоченной доставки, но библиотека раскрывает лишь упорядоченный поток байтов. Для работы Berkeley Sockets API и библиотека должны раскрыть транспортное свойство неупорядоченной доставки (или использовать это свойство без его раскрытия на основе информации о приложении, но это не подходит в общем случае). Точно так же транспортные протоколы, такие как SCTP, предлагают многопотоковую передачу, которая не может использоваться, например, для приоритизации сообщений в разных потоках, пока приложения не обмениваются значениями приоритета, которые следует применять, и группой соединений для этого. В большинстве случаев для максимальной гибкости и эффективности лучшим решением для библиотеки будет раскрытие по меньшей мере тех возможностей, которые включены здесь в «минимальный набор».

«Минимальный набор» можно реализовать «односторонне» на основе TCP. Это означает, что транспортная система на стороне отправителя может взаимодействовать со стандартным получателем TCP, а на стороне получателя – со стандартным отправителем TCP. С некоторыми ограничениями возможна реализация минимального набора на одной стороне по протоколу UDP. Хотя возможность реализации на одной стороне может быть полезна при развертывании, за это приходится платить ограничением набора услуг, которые могут быть предоставлены TCP (с большими ограничениями и UDP). Таким образом, минимальный набор применим для многих, но не для всех приложений, поскольку некоторые прикладные протоколы предъявляют требования, не выполнимые минимальным набором.

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

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

Transport Feature – транспортная функция (свойство)

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

Transport Service – транспортный сервис (служба)

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

Transport Protocol – транспортный протокол

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

Application – приложение

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

Application-specific knowledge

Информация, которую имеет лишь приложение.

End system – конечная система

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

Connection – соединение

Общее состояние двух или более конечных систем, сохраняемое в сообщениях между этими системами.

Connection Group – группа соединений

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

Socket – сокет

Комбинация IP-адреса и номера порта у получателя.

Кроме того, в этом документе применяется термин UDP(-Lite) при обсуждении транспортных свойств, присущих UDP и UDP-Lite. Точно так же TCP обозначает TCP и MPTCP.

3. Определение минимального набора

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

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

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

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

Подход к определению минимального набора транспортных свойств описана ниже.

  1. Классификация (Приложение A). Представлено надмножество транспортных свойств из [RFC8303] и эти функции разделены на функциональные, оптимизационные и автоматизируемые.

  2. Сокращение (раздел 4). Сокращенный список транспортных свойств выводится из категорий п. 1. при этом исключаются все транспортные функции, которые не требуют сведений от конкретных приложений или могут приводить к семантически некорректному поведению при реализации на основе TCP или UDP.

  3. Обсуждение (раздел 5). Полученный в результате список показывает набор обсуждаемых свойств для определения основы при выводе минимального набора свойств.

  4. Построение (раздел 6). На основе сокращения и обсуждения транспортных свойств определяется их минимальный набор.

Следуя [RFC8303] и сохраняя принятую там терминологию транспортные функции поделены на две основных группы.

  1. Связанные с соединением транспортные функции:

    • организация;

    • доступность;

    • поддержка;

    • завершение.

  2. Связанные с передачей данных транспортные функции:

    • передача данных;

    • прием данных;

    • ошибки.

4. Сокращенный набор транспортных функций

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

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

Приведенный ниже список содержит транспортные функции из Приложения A, сокращенные с использованием приведенных правил. Выведенный в документе «минимальный набор» может быть реализован на одной стороне по протоколу TCP и с некоторыми ограничениями – UDP. В списке транспортные функции помечены T:, если возможна реализация на основе TCP, U: – для UDP и T,U: – когда возможна реализация на основе обоих протоколов.

4.1. Связанные с соединением транспортные функции

Организация

  • T,U: соединение;

  • T,U: задание числа попыток и/или тайм-аута для первого сообщения организации соединения;

  • T,U: отключение MPTCP;

  • T: настройка аутентификации;

  • T: отправка сообщения для гарантированной передачи (возможно неоднократная) до соединения;

  • T: отправка сообщения для гарантированной передачи при организации соединения.

Доступность

  • T,U: прослушивание;

  • T,U: отключение MPTCP;

  • T: настройка аутентификации.

Поддержка

  • T: смена тайм-аута разрыва соединения (ограничение числа повторов или время);

  • T: предложенный партнеру тайм-аут;

  • T,U: отключение алгоритма Nagle;

  • T,U: уведомление об избыточных повторах (упреждение перед достижением порога разрыва);

  • T,U: указание поля DSCP;

  • T,U: уведомление о получении сообщения ICMP об ошибке;

  • T: смена параметров аутентификации;

  • T: получение данных аутентификации;

  • T,U: установка значение Cookie;

  • T,U: выбор планировщика для управления потоками в ассоциации;

  • T,U: настройка приоритета или веса для палнировщика;

  • T,U: отключение контрольных сумм при передаче;

  • T,U: запрет требования контрольной суммы на приеме;

  • T,U: задание покрытия контрольной суммы, используемой отправителем;

  • T,U: задание минимального покрытия контрольной суммы, требуемого получателем;

  • T,U: задание поля DF;

  • T,U: получение максимального размера транспортного сообщения, которое может быть передано без фрагментации IP, от настроенного интерфейса;

  • T,U: получение максимального размера транспортного сообщения, которое может быть принято, от настроенного интерфейса;

  • T,U: получение поля ECN;

  • T,U: включение и настройка LEDBAT6.

Завершение

  • T: закрытие после гарантированной доставки всех оставшихся данных, вызывающее событие для информировании приложения на другой стороне;

  • T: разрыв без доставки оставшихся данных, вызывающий информирование приложения на другой стороне;

  • T,U: разрыв без доставки оставшихся данных и без информирования приложения на другой стороне;

  • T,U: тайм-аут, когда данные не могут быть доставлены слишком долго.

4.2. Связанные с передачей данных транспортные функции

4.2.1. Передача данных

  • T: гарантированная доставка данных с контролем перегрузок;

  • T: гарантированная доставка сообщения с контролем перегрузок;

  • T,U: доставка данных без гарантии;

  • T: настраиваемые гарантии доставки сообщений;

  • T: упорядоченная доставка сообщений (может быть медленней неупорядоченной);

  • T,U: неупорядоченная доставка сообщений (потенциально быстрее упорядоченной);

  • T,U: запрос передачи сообщений без группировки (bundle);

  • T: задание идентификатора ключа для проверки подлинности сообщений;

  • T,U: запрос передачи подтвеждений без задержки (SACK).

4.2.2. Прием данных

  • T,U: получение данных (без разграничения сообщений);

  • U: получение сообщений;

  • T,U: информирование о частичной доставке сообщения.

4.2.3. Ошибки

В этом параграфе указаны отказы при передаче, связанные с конкретными вызовами категории «передача данных» (A.2.1. Передача).

  • T,U: уведомление об отказе при передаче;

  • T,U: уведомление о том, что стек больше не имеет пользовательских данных для передачи;

  • T,U: уведомление получателя о прерывании частичной доставки сообщения.

5. Обсуждение

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

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

5.1. Передача сообщений, прием байтов

Для реализации транспортной системы на основе TCP имеется несколько транспортных функций, относящихся к передаче, и лишь одна функция, связанная с приемом – получение сообщений без их разграничения (а также, как ни странно, информирование о частичной доставке сообщения). Примечательно, что транспортная функция приема сообщения является единственной не автоматизируемой функцией UDP(-Lite), для которой невозможна реализация на основе TCP.

Для поддержки семантики получателя TCP определен «кадрированный приложением поток байтов (Application- Framed Byte Stream или байтовый поток AFra). Байтовые потоки AFra позволяют отправителям работать с сообщениями при минимальном изменении API сокета TCP. В частности, на приемной стороне изменений просто не требуется и данные можно принимать через обычный соект TCP.

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

Например, если приложение запрашивает передачу сообщений постоянного размера 100 байтов с частичными гарантиями, принимающему приложению нужно быть готовым к приему 100-байтовых блоков. Приложению также нужно быть готовым к отсутствию некоторых блоков (например, в результате применения SCTP с настраиваемыми гарантиями). При использовании TCP пропусков блоков не будет, но это верно и для приложения, а возможная задержка из-за повтора приемлема в модели обслуживания по возможности (best-effort, См. параграф 3.5 в [RFC7305]). Тем не менее, принимающее приложение будет делить поток байтов на 100-байтовые блоки.

Отметим, что такое использование сообщений не требует одинакового их размера. Многие прикладные протоколы используют формат TLV (Type-Length-Value – тип, размер, значение), например, определяя заголовки с полем размера или используя методы заполнения байтов, такие как COBS (Consistent Overhead Byte Stuffing) [COBS]. Если приложению нужны номера сообщений, например для восстановления порядка, это тоже должно указывать само приложение, поскольку транспортные свойства SCTP, связанные с порядковыми номерами, не включаются в минимальный набор (в интересах применения TCP).

5.2. Планировщики потоков без потока

Выше уже отмечено, что многопоточность не требует относящихся к приложению сведений. Возможные преимущества или недостатки в результате использования, например, двух потоков ассоциации SCTP в сравнении с применением двух отдельных ассоциаций SCTP или соединений TCP связаны с информацией о сети и конкретном транспортном протоколе, а не о приложении. Однако транспортные функции «выбора планировщика для потоков в ассоциации» и «настройки приоритета или веса в планировщике» работают с потоками, которыми здесь называются каналы связи, с которыми работает планировщик и которым назначается приоритет. Кроме того, транспортные функции категории «Поддержка» работают с ассоциациями в случае SCTP, т. е. применяются ко всем потокам в рамках ассоциации.

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

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

5.3. Упреждающая передача данных

Есть две транспортных функции, связанные с упреждающей передачей сообщений (возможно многократной) – TCP Fast Open [RFC7413] и «Передача сообщения для гарантированной доставки в процессе организации соединения», которая относится к способности SCTP передавать данные вместе с блоком COOKIE-Echo. Даже без TCP Fast Open протокол TCP может передавать данные в процессе согласования вместе с пакетом SYN, однако получатель таких данных может не передать их приложению, пока согласование не завершится. В разных вариантах TCP Fast Open эти данные не разграничены как сообщение протоколом TCP (не представляются сообщением). Эта функциональность обычно доступна в TCP и поддерживается несколькими реализациями, хотя спецификация TCP не указывает способ передачи таких данных приложениям.

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

Объем данных, которые можно успешно передать до или в процессе организации соединения, зависит от разных факторов, включая транспортный протокол, использование опций заголовка, выбор IPv4 или IPv6, а также Path MTU. Поэтому транспортной системе следует разрешать отправку приложению максимального объема данных, которые могли быть переданы до или в процессе организации соединения.

5.4. Работа отправителя «всухую»

Транспортная функция «уведомления отсутствия в стеке данных для передачи» относится к уведомлению SCTP SENDER DRY. Такие уведомления могут в принципе использоваться для предотвращения избыточно больших буферов передачи, сохраняя гарантию того, что транспортный отправитель всегда имеет данные для передачи. Это может обеспечивать преимущества некоторым приложениям [WWDC2015]. Однако SENDER DRY на деле означает, что весь буфер передачи (включая неотправленные и неподтвержденные данные) пуст, т. е. это уведомляет отправителя, но уже слишком поздно, когда у транспортного протокола уже нет данных для передачи. Некоторые современные реализации TCP включают отсутствующую в спецификации опцию сокета TCP_NOTSENT_LOWAT, которая предложена в [WWDC2015] и ограничивает объем неотправленных данных, которые TCP может сохранять в буфере сокета. Это позволяет задать уровень заполнения буфера, при котором сокет открывается для записи, без ожидания опустошения буфера.

SCTP позволяет также настроить размер буфера на стороне отправителя – автоматизируемая транспортная функция «настроить размер буфера передачи» обеспечивает это, но только для всего буфера, который включает неотправленные и неподтвержденные данные. SCTP не позволяет настраивать эти части раздельно. Поэтому для транспортной системы имеет смысл разрешать однотипный доступ в TCP_NOTSENT_LOWAT и уведомлениями SENDER DRY.

5.5. Профиль производительности

Транспортные функции включают:

  • запрет алгоритма Nagle;

  • включение и настройку LEDBAT;

  • указание поля DSCP.

Все они связаны с приложениями класса QoS, такими как низкая задержка или сборка мусора (scavenger). В интересах гибкости транспортной системы они могут предлагаться в однородной, более абстрактной форме, когда транспортная система может, например, решить самостоятельно как использовать контроль перегрузок в стиле LEDBAT и выбрать определенные значения DSCP, а приложение будет лишь задавать общий профиль производительности (описание способа ее получения). Потребность в «минимально возможной задержке за счет издержек» можно тогда транслировать в автоматическое отключение алгоритма Nagle.

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

5.6. Защита

Протоколы TCP и SCTP предлагают аутентификацию. TCP аутентифицирует полные сегменты. SCTP позволяет настраивать типы блоков SCTP, которые всегда должны аутентифицироваться и если такая возможность раскрывается, она создает нежелательную зависимость от транспортного протокола. Для совместимости с TCP транспортной системе следует позволять лишь настройку для полный пакетов транспортного уровня, включая заголовки, псевдозаголовок IP (при наличии) и данные (payload).

Защита рассматривается в отдельном документе [RFC8922]. Представленный здесь минимальный набор включает все связанные с защитой транспортные функции из Приложения A – настраиваемую аутентификацию, смену параметров аутентификации, получение данных аутентификации, установку значения Cookie life, а также задание ключа для аутентификации сообщения. Включены также транспортные функции, не указанные в приложении A, такие как приватность содержимого на промежуточных устройствах.

5.7. Размер пакета

UDP(-Lite) включает транспортную функцию задания поля DF. Это вызывает сообщения об ошибке в случае отправки сообщений размером больше Path MTU, которые нужны приложению на основе UDP для реализации механизма Path MTU Discovery (функция, которую приложения на базе UDP должны выполнять самостоятельно). Транспортная функция определения максимального размера транспортного сообщения, которое можно передать в пакете IP без фрагментации с заданного интерфейса, дает верхний предел для Path MTU (без заголовков) и может поэтому реализовать Path MTU Discovery более эффективно.

6. Минимальный набор транспортных свойств

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

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

Как в разделах 3, 4 и [RFC8303] минимальный набор транспортных функций разделен на категории, связанные с 1) соединениями (организация, доступность, поддержка, завершение) и 2) передачей данных (отправка данных, прием данных, ошибки). Здесь основное внимание уделено соединениям, которые транспортные системы в абстрактной форме предлагают приложениям, в отличие от соединений транспортных протоколов, используемых транспортной системой.

6.1. Организация, доступность, завершение

Сначала должно быть «организовано» соединение, чтобы можно было выполнить ту или иную начальную настройку, прежде чем транспортная система сможет организовать пассивное или активное взаимодействие с удаленной конечной системой. При настройке вновь созданного соединения приложение может отказаться от использования MPTCP. Кроме того, все параметры конфигурации из параграфа 6.2 могут применяться изначально, хотя некоторые из них начнут работать лишь после организации соединения с выбранным транспортным протоколом. Ранняя настройка соединения помогает транспортной системе принять верное решение. Например, данные о группировке могут повлиять на решение вопроса о реализации соединения в форме потока многопоточного протокола в имеющейся ассоциации.

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

      +----------------------------------------------------------+
      | Потребуется ли предлагать что-либо из перечисленного?    |
      | * Гарантии доставки данных                               |
      | * Уведомление партнера о закрытии или прерывании         |
      | * Сохранение порядка данных                              |
      +----------------------------------------------------------+
                |                                    |
                |Да                                  |Нет
                | (Можно применять)                  | (Можно применять 
                |  SCTP или TCP)                     |  все протоколы)
                V                                    V
+--------------------------------------+ +-----------------------------+
| Полезно ли приложению что-либо       | | Полезно ли приложению что-то|
| из перечисленного?                   | | из перечисленного?          |
| * Выбор планировщика для работы с    | | * Задание покрытия контрол. |
|   соединениями в группе с            | |   суммы у отправителя       |
|   возможностью задать приоритет или  | | * Задание минимального      |
|   вес на уровне соединения           | |   покрытия контрольн. суммы,|
| * Настраиваемые гарантии для сообщен.| |   требуемого получателем    |
| * Неупорядоченная доставка сообщений | +-----------------------------+
| * Запрос передачи подтверждений      |         |             |
|   (SACK) без задержки                |         |Да           |Нет
+--------------------------------------+         |             |
          |                |                     |             |
          |Да              |Нет                  |             |
          V                |                     V             V
        Предпочтителен     |              Предпочтителен  Предпочтителен
        SCTP.              |                UDP-Lite.       UDP.
                           V
+------------------------------------------------------+
| Полезно ли приложению что-либо из перечисленного?    |
| * Передача сообщения (возможно неоднократная)        |
|   для гарантированной доставки до организ. соединения|
| * Предложение тайм-аута партнеру                     |
| * Уведомление об избыточных повторах (заранее до     |
|   достижения порога разрыва)                         |
| * Уведомление о прибытии сообщения ICMP об ошибке    |
+------------------------------------------------------+
          |                            |
          |Да                          |Нет
          V                            V
   Предпочтителен TCP.            SCTP и TCP равноценны.


Отметим, что это дерево решений не является оптимальным для всех случаев. Например, если приложение хочет использовать задание области покрытия контрольной суммы отправителем, которое предлагает лишь UDP-Lite, и настройку приоритета или веса для планировщика, которая доступна только в SCTP, выбор в соответствии с представленным деревом всегда приводит к UDP-Lite, делая невозможным использование планировщиков SCTP с планировщиками по приоритету внутри группы соединений. Есть и другие факторы, способные влиять на выбор протокола (за или против), например уровень распространенности, возможность работы через NAT и т. п. Разработчикам следует принимать во внимание все компромиссные требования, указанные в параграфе 4.1, при выборе способа инициализации соединения.

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

Reliability (надежность)

Логическая переменная, в которой следует устанавливать значение true, когда приложению полезно использовать что-либо из числа перечисленного: надежная доставка данных, уведомление партнера о закрытии или разрыве соединения, упорядоченность данных.

Checksum coverage (покрытие контрольной суммы)

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

Configure message priority (настраиваемый приоритет сообщений)

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

Early message timeout notifications (упреждающее информирование о тайм-ауте)

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

После организации соединения для него можно запросить максимальный объем данных, для которых приложение может ожидать гарантированную передачу до или в процессе организации транспортного соединения (с возможностью указать 0), как указано в параграфе 6.2.1. Приложение также может передавать в соединение сообщения для гарантированной доставки до или в процессе организации соединения (не-UDP), после чего транспортная система будет передавать их как можно раньше. Приложение может облегчить отправку сообщения как можно раньше, пометив его как «идемпотентное» (6.3.1. Передача) и в этом случае принимающая сторона должна быть гтова к возможности получения нескольких копий сообщения (поскольку идемпотентные сообщения передаются с гарантиев, запрос идемпотентности не требуется для систем, поддерживающих UDP).

После создания транспортная система может активно организовать соединение с партнером или пассивно прослушивать входящие вызовы. Отметим, что активная организация соединения может (но не обязательно) вызывать уведомление слушающей стороны. Возможно получение слушающей стороной уведомления вместе с первыми данными от активной стороны (транспортная система на приемной стороне может обрабатывать это, продолжая блокировать вызов Listen, за которым следует, например, вызов Receive; реализации callback могут просто пропустить эквивалент Listen). Это также означает, что активная сторона считается первой в передаче данных.

Транспортная система может активно закрыть соединение, т. е. прервать его после гарантированной доставки партнеру всех оставшихся данных (если раньше была запрошена гарантированная доставка, не UDP) и в этом случае партнер уведомляется о закрытии соединения. Кроме того, соединение может быть разорвано без доставки партнеру оставшихся данных. В случае запрошенной ранее гарантированной или почти гарантированной доставки (не-UDP) партнер уведомляется о разрыве соединения. Может быть задан тайм-аут для разрыва соединения с случае, когда данные не доставляются слишком долго (не-UDP), однако при разрыве по тайм-ауту партнер не уведомляется о разрыве соединения. Поскольку полуоткрытые соединения не поддерживаются, при получении реализующим транспортную систему хостом уведомления от партнера о закрытии или разрыве соединения (не-UDP) может оказаться невозможным прочтение остающихся данных. Это значит, что неподтвержденные данные в буфере передачи транспортной системы могут быть отброшены из буфера при получении от партнера уведомления close или abort.

6.2. Поддержка

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

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

6.2.1. Группы соединений

Перечисленные ниже транспортные свойства и уведомления (некоторые напрямую из раздела 4, иные новые или измененные на основе раздела 5) автоматически применяются ко всем сгруппированным соединениям.

Настройка тайм-аута (не-UDP)

Это может выполняться со следующими параметрами:

  • значение тайм-аута для разрыва соединения (в секундах);
  • предлагаемое партнеру (если возможно) значение тайм-аута (в секундах);
  • число повторов, по достижении которого приложение следует информировать об избыточных повторах (Excessive Retransmissions).

Настройка важности (срочности)

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

  • Число для идентификации планировщика, который следует использовать для работы с соединениями внутри группы (без гарантий). Планировщики определены в [RFC8260].
  • Номер «профиля производительности» для указания способа использования приложением доступной производительности. Вариантами могут быть «наименьшая возможная задержка за счет накладных расходов» (отключает любой алгоритм в стиле Nagle), «сборка мусора» (scavenger) или иные значения, помогающие определить DSCP для соединения.
  • Предельный размер буфера (в байтах). Приложение может уведомляться, когда у отправителя в буфере объем данных меньше установленного предела. Уведомления не гарантируются и транспортная система не обязана поддерживать предельный размер буфера больше 0. Отметим, что этот предел и уведомления следует применять для буферов всей транспортной системы, т. е. для любых возможных буферов, которые сама транспортная система может применять «поверх» транспортного буфера передачи.

В соответствии с параграфом 5.7 можно запросить перечисленные ниже свойства.

  • Максимальный размер сообщений, которые можно передать без фрагменттации через настроенный интерфейс. Транспортная система не обязана предоставлять это свойство и может возвращать ошибку (not available). Это свойство может помочь приложениям, реализующим Path MTU Discovery.

  • Максимальный размер транспортного сообщения, которое можно передать (в байтах). Независимо от фрагментации имеется предельный размер для сообщений, обслуживаемых SCTP или UDP(-Lite). Поскольку предоставляемые транспортной системой услуги не зависят от транспортного протокола, система должна позволять приложениям запрашивать это значение – максимальный размер сообщения в кадрированном приложением потоке байтов (AFra, параграф 5.1). Система может возвращать ошибку (not available), если данные не разграничиваются.

  • Максимальный размер транспортного сообщения, которое может быть принято от настроенного интерфейса (в байтах) или not available.

  • Максимальный объем данных, которые можно передать до организации соединения (в байтах).

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

Excessive Retransmissions – избыточные повторы передачи

Достигнуто настроенное (или принятое по умолчанию) число повторов передачи, что является упреждающим разрыв соединения уведомлением.

ICMP Arrival – прибытие ICMP (параметром является сообщение ICMP)

Прибыл пакет ICMP, содержащий сообщение ICMP.

ECN Arrival – прибытие ECN (параметром является значение ECN)

Прибыл пакет с явным уведомлением о перегрузке (Explicit Congestion Notification или ECN). Это может быть полезно для приложений с контролем перегрузки.

Timeout – тайм-аут (параметром служит число секунд)

Данные не могут быть доставлены в течение s секунд.

Drain:

Буфер передачи был опустошен ниже заданного предела или полностью. Это базовое уведомление, которое пытается включить унифицированный доступ к TCP_NOTSENT_LOWAT, а также уведомлению SENDER DRY (как описано в параграфе 5.4, SCTP SENDER DRY является особым случаем, где порог для неотправленных данных равен 0 и в буфере передачи не осталось неподтвержденных данных).

6.2.2. Отдельные соединения

Настройка приоритета или веса для планировщика в соответствии с [RFC8260].

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

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

  • Желаемая область покрытия контрольной суммой (в байтах) при передаче.

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

  • Требуемая минимальная область покрытия контрольной суммой (в байтах) при получении.

6.3. Обмен данными

6.3.1. Передача

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

Reliability – гарантия доставки

Этот параметр служит для указания выбора – полностью надежная доставка с контролем перегрузки (не-UDP), доставка без гарантий и контроля перегрузки, доставка без гарантий с контролем перегрузки (не-UDP), частичные гарантии с контролем перегрузки (см. [RFC3758] и [RFC7496], где приведено описание частичных гарантий) (не-UDP). Два последних варианта транспортная система не обязана предлагать и это может приводить к полной гарантии. Отметим, что приложению, передающему данные без гарантий и контроля перегрузок, следует самому контролировать перегрузки в соответствии с [RFC8085].

Ordered – упорядоченность (не-UDP)

Логическое значение, позволяющее приложению выбрать упорядоченную (true) или неупорядоченную (false), но возможно более быструю доставку сообщений.

Bundle – связка (группировка)

Логическое значение, разрешающее (true) или запрещающее (false) группировать сообщения. Без гарантий.

DelAck – задержка подтверждения

Логическое значение, позволяющее приложению запросить (false) у партнера отправку подтверждения доставки этого сообщения без задержки.

Fragment – фрагментирование

Логическое значение, разрешающее (true) или запрещающее (false) фрагментировать сообщения на уровне IP. Без гарантий.

Idempotent – идемпотентность (не-UDP)

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

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

6.3.2. Прием

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

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

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

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

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

Аутентификация, защита конфиденциальности и целостности указаны как транспортные свойства в [RFC8095]. Зачастую эти свойства обеспечиваются протоколом или уровнем над транспортным протоколом. Ни один из полнофункциональных стандартных протоколов из [RFC8303], на которых базируется этот документ, не поддерживает все эти транспортные функции, поэтому они не рассматриваются в данном документе, за исключением естественных функций аутентификации в TCP и SCTP, к которым применимо рассмотрение вопросов безопасности в [RFC5925] и [RFC4895]. Минимальные требования к защищенной транспортной системе рассмотрены в отдельном документе [RFC8922].

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

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

[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., “Services Provided by IETF Transport Protocols and Congestion Control Mechanisms”, RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.

[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, “On the Usage of Transport Features Provided by IETF Transport Protocols”, RFC 8303, DOI 10.17487/RFC8303, February 2018, <https://www.rfc-editor.org/info/rfc8303>.

[RFC8922] Enghardt, T., Pauly, T., Perkins, C., Rose, K., and C. Wood, “A Survey of the Interaction between Security Protocols and Transport Services”, RFC 8922, DOI 10.17487/RFC8922, October 2020, <https://www.rfc-editor.org/info/rfc8922>.

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

[COBS] Cheshire, S. and M. Baker, “Consistent overhead byte stuffing”, IEEE/ACM Transactions on Networking, Volume 7, Issue 2, DOI 10.1109/90.769765, April 1999, <https://doi.org/10.1109/90.769765>.

[POSIX] The Open Group, “IEEE Standard for Information Technology–Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7”, (Revision of IEEE Std 1003.1-2008), IEEE Std 1003.1-2017, January 2018, <https://www.opengroup.org/onlinepubs/9699919799/functions/contents.html>.

[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, “Stream Control Transmission Protocol (SCTP) Partial Reliability Extension”, RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.

[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, “Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)”, RFC 4895, DOI 10.17487/RFC4895, August 2007, <https://www.rfc-editor.org/info/rfc4895>.

[RFC4987] Eddy, W., “TCP SYN Flooding Attacks and Common Mitigations”, RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, “The TCP Authentication Option”, RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[RFC6897] Scharf, M. and A. Ford, “Multipath TCP (MPTCP) Application Interface Considerations”, RFC 6897, DOI 10.17487/RFC6897, March 2013, <https://www.rfc-editor.org/info/rfc6897>.

[RFC7305] Lear, E., Ed., “Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)”, RFC 7305, DOI 10.17487/RFC7305, July 2014, <https://www.rfc-editor.org/info/rfc7305>.

[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, “TCP Fast Open”, RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.

[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, “Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension”, RFC 7496, DOI 10.17487/RFC7496, April 2015, <https://www.rfc-editor.org/info/rfc7496>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, “UDP Usage Guidelines”, BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, “Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol”, RFC 8260, DOI 10.17487/RFC8260, November 2017, <https://www.rfc-editor.org/info/rfc8260>.

[RFC8304] Fairhurst, G. and T. Jones, “Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)”, RFC 8304, DOI 10.17487/RFC8304, February 2018, <https://www.rfc-editor.org/info/rfc8304>.

[RFC8622] Bless, R., “A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services”, RFC 8622, DOI 10.17487/RFC8622, June 2019, <https://www.rfc-editor.org/info/rfc8622>.

[SCTP-STREAM-1] Weinrank, F. and M. Tuexen, “Transparent Flow Mapping for NEAT”, IFIP Networking 2017, Workshop on Future of Internet Transport (FIT 2017), June 2017.

[SCTP-STREAM-2] Welzl, M., Niederbacher, F., and S. Gjessing, “Beneficial Transparent Deployment of SCTP: The Missing Pieces”, IEEE GlobeCom 2011, DOI 10.1109/GLOCOM.2011.6133554, December 2011, <https://doi.org/10.1109/GLOCOM.2011.6133554>.

[TAPS-INTERFACE] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., and T. Pauly, “An Abstract Application Layer Interface to Transport Services”, Work in Progress, Internet-Draft, draft-ietf-taps-interface-09, 27 July 2020, <https://tools.ietf.org/html/draft-ietf-taps-interface-09>.

[WWDC2015] Lakhera, P. and S. Cheshire, “Your App and Next Generation Networks”, Apple Worldwide Developers Conference 2015, San Francisco, USA, June 2015, <https://developer.apple.com/videos/wwdc/2015/?id=719>.

Приложение A. Расширенное множество транспортных функций

В этом приложении представлены транспортные свойства в соответствии с номенклатурой «Категория.[Субкатегория].Свойство.Протокол» (CATEGORY.[SUBCATEGORY].FEATURENAME.PROTOCOL), эквивалентной этапу 2 в [RFC8303]. Очерчена также реализация транспортной системой транспортных свойств (функций). «Минимальный набор», заданный в этом документе, предназначен для «односторонней» реализации по протоколу TCP и (с некоторыми ограничениями) UDP. Поэтому для всех транспортных функций, отнесенных к категории «функциональные» или «оптимизирующие», для которых нет соответствующих примитивов TCP и/или UDP на этапе 2 в [RFC8303], приведено краткое описание реализации на основе TCP и/или UDP.

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

  • Большинство транспортных функций, связанных с многопоточностью, помечены как автоматизируемые, поскольку принятие решения об использовании множества потоков не требует знаний о конкретном приложении. Это значит, что соединение, предоставляемое приложению, может быть реализовано с использованием одного потока ассоциации SCTP вместо использования всей ассоциации или соединения TCP. Это можно сделать путем использования более одного потока в момент создания ассоциации SCTP (параметр CONNECT.SCTP – число исходящих потоков), поддержки внутренних номеров потоков и их применения при передаче данных (параметр SEND.SCTP – номер потока). Закрытие или разрыв соединения может просто освобождать номер потока для последующего использования (См. параграф 5.2).

  • Все транспортные функции, кроме отключения MPTCP, связанные с использованием нескольких путей или выбором сетевого интерфейса, считаются автоматизируемыми. Например, Listen всегда может прослушивать все доступные интерфейсы, а Connect – использовать принятый по умолчанию интерфейс для целевого адреса IP.

В трех случаях транспортные функции в приведенном ниже описании были собраны вместе или слегка изменены по сравнению с [RFC8303] и эти отличия специально помечены. Они не добавляют новых функций, а просто представляют некий пересмотр, который поможет упростить процесс вывода (например, за счет удаления параметров для приложений, которые могут не заботиться о своем выборе. Соответствующие транспортные функции являются автоматизируемыми и они помечены ниже как отличающиеся от RFC 8303.

A.1. Связанные с соединением транспортные свойства

Организация

Connect

Протоколы: TCP, SCTP, UDP(-Lite).

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

Реализация: CONNECT.TCP, CONNECT.SCTP, CONNECT.UDP(-Lite).

Задание опций IP, которые должны применяться всегда

Протоколы: TCP, UDP(-Lite).

Автоматизируемо, поскольку опции IP относятся к информации о сети, а не о приложении.

Запрос множества потоков

Протоколы: SCTP.

Автоматизируемо, поскольку применение множества потоков не требуется связанного с приложением знания (примеры реализации множества потоков без участия приложения даны в [SCTP-STREAM-1] и [SCTP-STREAM-2]).

Реализация: См. параграф 5.2.

Ограничение числа входящих потоков

Протоколы: SCTP.

Автоматизируемо, поскольку применение множества потоков не требуется связанного с приложением знания.

Реализация: См. параграф 5.2.

Задание числа попыток и/или тайм-аутов для первого сообщения при организации

Протоколы: TCP, SCTP.

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

Реализация: Используются параметры CONNECT.TCP и CONNECT.SCTP.

Реализация на основе UDP: Ничего (безотносительно к варианту UDP, поскольку гарантии не предполагаются).

Получение множества сокетов

Протоколы: SCTP.

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

Отключение MPTCP

Протоколы: MPTCP.

Оптимизируемо, поскольку непараллельное применение множества путей для связи между теми же конечными хостами может повышать производительность. Применение этого свойства зависит от информации о сети и приложении (См. параграф 3.1 of [RFC6897]).

Реализация: С помощью логического параметра в CONNECT.MPTCP.

Реализация с TCP: Ничего.

Реализация с UDP: Ничего.

Настройка аутентификации

Протоколы: TCP, SCTP.

Функционально, поскольку напрямую влияет на безопасность.

Реализация: Через параметры в CONNECT.TCP и CONNECT.SCTP. С TCP это позволяет настроить кортежи первичных ключей (Master Key Tuple или MKT) для аутентификации полных сегментов (включая псевдозаголовок TCP IPv4, заголовок и данные TCP). В SCTP это позволяет задать типы аутентифицируемых блоков. Аутентификация лишь определенных типов блоков снижает уровень защиты, что не поддерживается в TCP. Для совместимости следует разрешать лишь аутентификацию всех блоков. Способ предоставления ключевого материала должен соответствовать [RFC4895] и [RFC5925].

Реализация с UDP: Невозможна (UDP не предлагает такой функциональности).

Указание (и/или получение по завершении) уровня адаптации с помощью его кода

Протоколы: SCTP.

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

Реализация: С помощью параметра в CONNECT.SCTP.

Реализация с TCP: Невозможна (TCP не предлагает такой функциональности).

Реализация с UDP: Невозможна (UDP не предлагает такой функциональности).

Запрос согласования для чередования пользовательских сообщений

Протоколы: SCTP.

Автоматизируемо, поскольку требует использования множества потоков, а запрос множества потоков в категории CONNECTION.ESTABLISHMENT является автоматизируемым.

Реализация: Контролируется через параметр в CONNECT.SCTP. Одной из возможных реализаций является попытка использовать чередования всегда.

Отправка сообщения с гарантией доставки (возможно несколько раз) до организации соединения

Протоколы: TCP.

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

Реализация: Через параметр в CONNECT.TCP.

Реализация с UDP: Невозможна (UDP не предлагает такой функциональности).

Отправка сообщения с гарантией доставки в процессе организации соединения

Протоколы: SCTP.

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

Реализация: Через параметр в CONNECT.SCTP.

Реализация с TCP: Передача сообщения в пакете SYN без возможности указать границы сообщения.

Реализация с UDP: Невозможна (UDP не предлагает такой функциональности).

Включение UDP-инкапсуляции с заданным удаленным портом UDP

Протоколы: SCTP.

Автоматизируема, поскольку инкапсуляция UDP относится к знанию о сети, а не о приложении.

Доступность

Listen

Протоколы: TCP, SCTP, UDP(-Lite).

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

RFC 8303 отличается от 3 автоматизируемых транспортных свойств, приведенных ниже, в том, что выбор интерфейса для прослушивания остается открытым.

Реализация: Прослушивание на всех интерфейсах с помощью LISTEN.TCP (не указан локальный IP-адрес) или LISTEN.SCTP (указаны пары «порт SCTP – адрес» для всех локальных адресов IP). LISTEN.UDP(-Lite) поддерживает оба метода.

Listen, 1 локальный интерфейс

Протоколы: TCP, SCTP, UDP(-Lite).

Автоматизируемо, поскольку решения о локальных интерфейсах связаны со знанием о сети и операционной системе, а не о приложении.

Listen, N локальных интерфейсов

Протоколы: SCTP.

Автоматизируемо, поскольку решения о локальных интерфейсах связаны со знанием о сети и операционной системе, а не о приложении.

Listen, все локальные интерфейсы

Протоколы: TCP, SCTP, UDP(-Lite).

Автоматизируемо, поскольку решения о локальных интерфейсах связаны со знанием о сети и операционной системе, а не о приложении.

Задание опций IP, которые должны применяться всегда

Протоколы: TCP, UDP(-Lite).

Автоматизируемо, поскольку опции IP относятся к знанию о сети, а не о приложении.

Отключение MPTCP

Протоколы: MPTCP.

Оптимизируемо, поскольку непараллельное применение множества путей для связи между теми же конечными хостами может повышать производительность. Применение этого свойства зависит от информации о сети и приложении (См. параграф 3.1 of [RFC6897]).

Реализация: Через логический параметр в LISTEN.MPTCP.

Реализация с TCP: Ничего.

Реализация с UDP: Ничего.

Настройка аутентификации

Протоколы: TCP, SCTP.

Функционально по причине прямого влияния на безопасность.

Реализация: Через параметры в LISTEN.TCP и LISTEN.SCTP.

Реализация с UDP: Невозможна (UDP не предлагает такой функциональности).

Реализация с TCP: С TCP это позволяет настроить кортежи первичных ключей (Master Key Tuple или MKT) для аутентификации полных сегментов (включая псевдозаголовок TCP IPv4, заголовок и данные TCP). В SCTP это позволяет задать типы аутентифицируемых блоков. Аутентификация лишь определенных типов блоков снижает уровень защиты, что не поддерживается в TCP. Для совместимости следует разрешать лишь аутентификацию всех блоков. Способ предоставления ключевого материала должен соответствовать [RFC4895] и [RFC5925].

Реализация с UDP: Невозможна (UDP не предлагает аутентификации).

Получение запрошенного числа потоков

Протоколы: SCTP.

Автоматизируемо, поскольку использование множества потоков не требует знания о приложении.

Реализация: См. параграф 5.2.

Ограничение числа входящих потоков

Протоколы: SCTP.

Автоматизируемо, поскольку использование множества потоков не требует знания о приложении.

Реализация: См. параграф 5.2.

Указание (и/или получение по завершении) кода уровня адаптации

Протоколы: SCTP.

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

Реализация: С помощью параметра в LISTEN.SCTP.

Реализация с TCP: Невозможна (TCP не предлагает такой функциональности).

Реализация с UDP: Невозможна (UDP не предлагает такой функциональности).

Запрос согласования для чередования пользовательских сообщений

Протоколы: SCTP.

Автоматизируемо, поскольку требует множество потоков, а запрос множества потоков в категории CONNECTION.ESTABLISHMENT является автоматизируемым.

Реализация: Через параметр в LISTEN.SCTP.

Поддержка

Смена тайм-аута для разрыва соединения (время или число повторов)

Протоколы: TCP, SCTP.

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

Реализация: Через CHANGE_TIMEOUT.TCP или CHANGE_TIMEOUT.SCTP.

Реализация с UDP: Невозможна (UDP не дает гарантий и не поддерживает тайм-аут для соединения).

Предложенный партнеру тайм-аут

Протоколы: TCP.

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

Реализация: Через CHANGE_TIMEOUT.TCP.

Реализация с UDP: Невозможна (UDP не дает гарантий и не поддерживает тайм-аут для соединения).

Отключение алгоритма Nagle

Протоколы: TCP, SCTP.

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

Реализация: Через DISABLE_NAGLE.TCP и DISABLE_NAGLE.SCTP.

Реализация с UDP: Ничего (UDP не реализует алгоритм Nagle).

Запрос немедленной передачи heartbeat с возвратом результата

Протоколы: SCTP.

Автоматизируемо, поскольку информирует о знании, относящемся к сети.

Уведомление об избыточных повторах (ранее до достижения порога разрыва)

Протоколы: TCP.

Оптимизируемо, поскольку это раннее предупреждение приложения, информирующее о приближающемся функциональном событии.

Реализация: Через ERROR.TCP.

Реализация с UDP: Ничего (нет порога разрыва соединения).

Добавление пути

Протоколы: MPTCP, SCTP.

Параметры MPTCP: source-IP, source-Port, destination-IP, destination-Port.

Параметры SCTP: Локальный адрес IP.

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

Удаление пути

Протоколы: MPTCP, SCTP.

Параметры MPTCP: source-IP, source-Port, destination-IP, destination-Port.

Параметры SCTP: Локальный адрес IP.

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

Задание основного пути

Протоколы: SCTP.

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

Предложение основного пути партнеру

Протоколы: SCTP.

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

Настройка переключения пути

Протоколы: SCTP.

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

Определение статуса (запрос или уведомление)

Протоколы: SCTP, MPTCP.

Параметры SCTP: Состояние соединения для ассоциации, список транспортных адресов получателей, состояния доступности транспортных адресов получателей, текущие размеры окна приема (локальный и у партнера), текущий размер локального окна перегрузки, число неподтвержденных блоков DATA, число блоков DATA, ожидающих приема, последнее значение SRTT на основном пути, RTO на основном пути, SRTT и RTO для других адресов получателей, MTU для путей, поддержка чередования (yes/no).

Параметры MPTCP: Список субпотоков (идентификация по source-IP, source-Port, destination-IP, destination-Port).

Автоматизируемо, поскольку эти параметры относятся к знанию о сети, а не о приложении.

Задание поля DSCP

Протоколы: TCP, SCTP, UDP(-Lite).

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

Реализация: Через SET_DSCP.TCP, SET_DSCP.SCTP, SET_DSCP.UDP(-Lite).

Уведомление о приеме сообщения ICMP об ошибке

Протоколы: TCP, UDP(-Lite).

Оптимизируемо, поскольку эти сообщения могут информировать об успехе или отказе функционального транспортного свойства (например, host unreachable относится к Connect).

Реализация: Через ERROR.TCP или ERROR.UDP(-Lite.).

Obtain information about interleaving support

Протоколы: SCTP.

Автоматизируемо, поскольку требует множество потоков, а запрос множества потоков в категории CONNECTION.ESTABLISHMENT является автоматизируемым.

Реализация: Через STATUS.SCTP.

Смена параметров аутентификации

Протоколы: TCP, SCTP.

Функционально по причине прямого влияния на безопасность.

Реализация: Через SET_AUTH.TCP и SET_AUTH.SCTP.

Реализация с TCP: В SCTP это позволяет настраивать key_id, key и hmac_id. В TCP это позволяет менять предпочтительный исходящий (current_key) и предпочтительный входящий (rnext_key) кортеж MKT для сегментов в соединении. Ключевой материал должен предоставляться способом, совместимым с [RFC4895] и [RFC5925].

Реализация с UDP: Невозможна (UDP не поддерживает аутентификацию).

Получение данных аутентификации

Протоколы: SCTP.

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

Реализация: Через GET_AUTH.SCTP.

Реализация с TCP: В SCTP это позволяет получить key_id и список блоков. В TCP это позволяет получить current_key и rnext_key из принятого ранее сегмента. Ключевой материал должен предоставляться способом, совместимым с [RFC4895] и [RFC5925].

Реализация с UDP: Невозможна (UDP не поддерживает аутентификацию).

Сброс потока

Протоколы: SCTP.

Автоматизируемо, поскольку применение множества потоков не требует знания о приложении.

Реализация: См. параграф 5.2.

Уведомление о сбросе потока

Протоколы: SCTP.

Автоматизируемо, поскольку применение множества потоков не требует знания о приложении.

Реализация: См. параграф 5.2.

Сброс ассоциации

Протоколы: SCTP.

Автоматизируемо, поскольку для решения о сбросе ассоциации не требует знания о приложении.

Реализация: Через RESET_ASSOC.SCTP.

Уведомление о сбросе ассоциации

Протоколы: SCTP.

Автоматизируемо, поскольку это уведомление не требует знания о приложении.

Добавление потоков

Протоколы: SCTP.

Автоматизируемо, поскольку применение множества потоков не требует знания о приложении.

Реализация: См. параграф 5.2.

Уведомление о добавлении потоков

Протоколы: SCTP.

Автоматизируемо, поскольку применение множества потоков не требует знания о приложении.

Реализация: См. параграф 5.2.

Выбор планировщика для потоков в ассоциации

Протоколы: SCTP.

Оптимизируемо, поскольку решение о выборе планировщика требует знаний о приложении. Однако, если транспортная система не будет выбирать планировщик или сама настроит выбор некорректно, это повлияет лишь на производительность доставки данных и результат останется корректным в рамках модели best effort.

Реализация: С использованием SET_STREAM_SCHEDULER.SCTP.

Реализация с TCP: Ничего (потоки недоступны в TCP и нет гарантий влияния этого транспортного свойства).

Реализация с UDP: Ничего (потоки недоступны в UDP и нет гарантий влияния этого транспортного свойства).

Настройка приоритета или веса для планировщика

Протоколы: SCTP.

Оптимизируемо, поскольку выбор приоритета или веса требует знания о приложении. Однако, если транспортная система не будет выбирать планировщик или сама настроит выбор некорректно, это повлияет лишь на производительность доставки данных и результат останется корректным в рамках модели best effort.

Реализация: С использованием CONFIGURE_STREAM_SCHEDULER.SCTP.

Реализация с TCP: Ничего (потоки недоступны в TCP и нет гарантий влияния этого транспортного свойства).

Реализация с UDP: Ничего (потоки недоступны в UDP и нет гарантий влияния этого транспортного свойства).

Настройка размера буфера передачи

Протоколы: SCTP.

Автоматизируемо, поскольку это решение связано со знанием о сети и операционной системе, а не о приложении (см. параграф 5.4).

Настройка размера приемного буфера (и rwnd)

Протоколы: SCTP

Автоматизируемо, поскольку это решение связано со знанием о сети и операционной системе, а не о приложении.

Настройка фрагментации сообщений

Протоколы: SCTP.

Автоматизируемо, поскольку это решение связано со знанием о сети и операционной системе, а не о приложении. Отметим, что это свойство SCTP не контролирует фрагментацию на уровне IP и относится лишь к фрагментации сообщений протоколом SCTP в конечной системе.

Реализация: Всегда выполняется путем включения через CONFIG_FRAGMENTATION.SCTP и автоматической настройки размера фрагментов в соответствии с условиями в сети и операционной системе.

Настройка PMTUD

Протоколы: SCTP.

Автоматизируемо, поскольку механизм Path MTU Discovery связан со знанием о сети, а не о приложении.

Настройка таймера задержки SACK

Протоколы: SCTP.

Автоматизируемо, поскольку решение принимающей стороны о задержке отправки SACK связано со знанием о сети, а не о приложении (для передающего приложения может относиться ка запросу не задерживать SACK, но это другое транспортное свойство).

Установка значения Cookie life

Протоколы: SCTP.

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

Реализация с TCP: Ближайшей похожей функциональностью TCP является cookie в TCP Fast Open. В [RFC7413] сказано, что сервер может в любой момент счесть cookie устаревшим в целях повышения уровня защиты, а в параграфе 4.1.2 [RFC7413] приведен пример реализации, где обновление ключа на стороне сервера ведет к завершению строка действия cookie. Для реализаций, не поддерживающих TCP Fast Open, это транспортное свойство может влияет на действительность SYN cookie (см. параграф 3.6 в [RFC4987]).

Реализация с UDP: Невозможна (UDP не поддерживает такой функциональности).

Установка максимального пика

Протоколы: SCTP.

Автоматизируемо, поскольку связано со знанием о сети, а не о приложении.

Настройка размера сообщений для частичной доставки

Протоколы: SCTP.

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

Реализация с TCP: Невозможна (TCP не предлагает идентификацию границ сообщения).

Реализация с UDP: Невозможна (UDP не фрагментируетсообщения).

Запрет контрольной суммы при отправке

Протоколы: UDP.

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

Реализация: Через SET_CHECKSUM_ENABLED.UDP.

Реализация с TCP: Ничего (TCP не предлагает отключать контрольные суммы, а передача данных с неповрежденной контрольной суммой не может давать семантически неверного результата).

Запрет требования контрольной суммы при получении

Протоколы: UDP.

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

Реализация: Через SET_CHECKSUM_REQUIRED.UDP.

Реализация с TCP: Ничего (TCP не предлагает отключать контрольные суммы, а передача данных с неповрежденной контрольной суммой не может давать семантически неверного результата).

Задание покрытия для контрольной суммы у отправителя

Протоколы: UDP-Lite.

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

Реализация: Через SET_CHECKSUM_COVERAGE.UDP-Lite.

Реализация с TCP: Ничего (TCP не предлагает ограничивать область охвата контрольной суммой, а передача данных с неповрежденной контрольной суммой не может давать семантически неверного результата).

Реализация с UDP: Если для контрольной суммы задано покрытие данных, не делает ничего. В иных случаях не делает ничего (передача данных с неповрежденной контрольной суммой не может давать семантически неверного результата) или используется транспортное свойство запрета контрольной суммы при передаче.

Минимальное покрытие для контрольной суммы, требуемое получателем

Протоколы: UDP-Lite.

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

Реализация: Через SET_MIN_CHECKSUM_COVERAGE.UDP-Lite.

Реализация с TCP: Ничего (TCP не предлагает ограничивать область охвата контрольной суммой, а передача данных с неповрежденной контрольной суммой не может давать семантически неверного результата).

Реализация с UDP: Если для контрольной суммы задано покрытие данных, не делает ничего. В иных случаях не делает ничего (передача данных с неповрежденной контрольной суммой не может давать семантически неверного результата) или используется транспортное свойство запрета контрольной суммы при передаче.

Задание поля DF

Протоколы: UDP(-Lite).

Оптимизируемо, поскольку поле DF может служить для передачи Path MTU Discovery и это может приводить к выбору приложением размера, обеспечивающего более эффективную доставку.

Реализация: Через MAINTENANCE.SET_DF.UDP(-Lite) и SEND_FAILURE.UDP(-Lite).

Реализация с TCP: Ничего (в TCP передающее приложение не контролирует размер транспортных сообщений).

Определение максимального размера транспортного сообщения для передачи без фрагментации IP через настроенный интерфейс

Протоколы: UDP(-Lite).

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

Реализация с TCP: Ничего (в TCP эта информация недоступна).

Определение максимального размера транспортного сообщения от настроенного интерфейса

Протоколы: UDP(-Lite).

Оптимизируемо, поскольку может влиять, например, на управление памятью в приложении.

Реализация с TCP: Ничего (в TCP эта информация недоступна).

Задание поля TTL/Hop Count

Протоколы: UDP(-Lite).

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

Получение поля TTL/Hop Count

Протоколы: UDP(-Lite).

Автоматизируемо, поскольку поле TTL/Hop Count связано со знанием о сети, а не о приложении.

Задание поля ECN

Протоколы: UDP(-Lite).

Автоматизируемо, поскольку поле ECN связано со знанием о сети, а не о приложении.

Получение поля ECN

Протоколы: UDP(-Lite).

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

Реализация с TCP: Ничего (в TCP эта информация недоступна).

Задание опций IP

Протоколы: UDP(-Lite).

Автоматизируемо, поскольку опции IP связаны со знанием о сети, а не о приложении.

Получение опций IP

Протоколы: UDP(-Lite).

Автоматизируемо, поскольку опции IP связаны со знанием о сети, а не о приложении.

Включение и настройка LEDBAT

Протоколы: Протокол, поддерживающий механизм контроля перегрузки LEDBAT.

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

Реализация: Через CONFIGURE.LEDBAT и/или SET_DSCP.TCP, SET_DSCP.SCTP, SET_DSCP.UDP(-Lite) [RFC8622].

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

Реализация с UDP: Ничего (UDP не предлагает контроля перегрузок).

Завершение

Закрытие после гарантированной доставки оставшихся данных с уведомлением приложения на другой стороне

Протоколы: TCP, SCTP

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

Реализация: Через CLOSE.TCP и CLOSE.SCTP.

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

Разрыв без доставки оставшихся данных с уведомлением приложения на другой стороне

Протоколы: TCP, SCTP.

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

Реализация: Через ABORT.TCP and ABORT.SCTP.

Реализация с UDP: Невозможна (UDP не указывает причину закрытия соединения партнером).

Разрыв без доставки оставшихся данных и уведомления приложения на другой стороне

Протоколы: UDP(-Lite).

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

Реализация: Через ABORT.UDP(-Lite).

Реализация с TCP: Прекращение использования соединения, ожидание тайм-аута.

Тайм-аут, когда данные не удается доставить слишком долго

Протоколы: TCP, SCTP.

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

Реализация: Через TIMEOUT.TCP и TIMEOUT.SCTP.

Реализация с UDP: Ничего (такое событие невозможно в UDP).

A.2. Связанные с обменом данными транспортные свойства

A.2.1. Передача

Гарантированная доставка данных с контролем перегрузок

Протоколы: TCP, SCTP.

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

Реализация: Через SEND.TCP и SEND.SCTP.

Реализация с UDP: Невозможна (UDP не предоставляет гарантий).

Гарантированная доставка сообщения с контролем перегрузок

Протоколы: SCTP.

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

Реализация: Через SEND.SCTP.

Реализация с TCP: Через SEND.TCP. Границы сообщения не видны получателю, поскольку TCP предоставляет услуги потока байтов.

Реализация с UDP: Невозможна (UDP не предоставляет гарантий).

Негарантированная доставка сообщения

Протоколы: SCTP, UDP(-Lite).

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

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

Реализация: Через SEND.SCTP или SEND.UDP(-Lite).

Реализация с TCP: Через SEND.TCP. Сообщения доставляются с гарантией, но получатель не видит границ.

Негарантированная доставка сообщения с контролем перегрузок

Протоколы: SCTP.

Автоматизируемо, поскольку контроль перегрузок связан со знанием о сети, а не о приложении.

Негарантированная доставка сообщения без контроля перегрузок

Протоколы: UDP(-Lite).

Автоматизируемо, поскольку контроль перегрузок связан со знанием о сети, а не о приложении.

Настраиваемые гарантии для сообщений

Протоколы: SCTP.

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

Реализация: Через SEND.SCTP.

Реализация с TCP: Выполняется через SEND.TCP и игнорирует эту настройку. В предположении модели сервиса best-effort доставка излишних данных не нарушает ожиданий приложения. Кроме того, в TCP невозможно связать запрашиваемые гарантии с сообщением.

Реализация с UDP: Невозможна (UDP не предоставляет гарантий).

Выбор потока

Протоколы: SCTP.

Автоматизируемо, поскольку требует множество потоков, а запрос множества потоков в категории CONNECTION.ESTABLISHMENT является автоматизируемым.

Реализация: См. параграф 5.2.

Выбор пути (адреса получателя)

Протоколы: SCTP.

Реализация с TCP: Н

Упорядоченная доставка сообщений (возможно медленней неупорядоченной)

Протоколы: SCTP.

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

Реализация: Через SEND.SCTP.

Реализация с TCP: Через SEND.TCP. Получатель не видит границ сообщения.

Реализация с UDP: Невозможна (UDP не предоставляет гарантий упорядоченности).

Неупорядоченная доставка сообщений (возможно быстрей упорядоченной)

Протоколы: SCTP, UDP(-Lite).

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

Реализация: Через SEND.SCTP.

Реализация с TCP: Выполняется через SEND.TCP с сохранением порядка. В предположении модели сервиса best-effort упорядоченная доставка не нарушает ожиданий приложения. Кроме того, в TCP невозможно связать запрос упорядоченной доставки с сообщением.

Запрос отмены группировки сообщений

Протоколы: SCTP.

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

Реализация: Через SEND.SCTP.

Реализация с TCP: Выполняется через SEND.TCP и DISABLE_NAGLE.TCP для запрета алгоритма Nagle по запросы и включении снова, когда запроса больше нет. Отметим неполную эквивалентность, связанную со временем подачи запроса, а не с конкретным сообщением.

Реализация с UDP: Ничего (UDP не группирует сообщений).

Задание идентификатора протокола в области данных (для получателя)

Протоколы: SCTP.

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

Реализация: SEND.SCTP.

Реализация с TCP: Невозможна (эта функциональность недоступна в TCP).

Реализация с UDP: Невозможна (эта функциональность недоступна в UDP).

Задание идентификатора ключа для аутентификации сообщения

Протоколы: SCTP.

Функционально по причине прямого влияния на безопасность.

Реализация: Через параметр SEND.SCTP.

Реализация с TCP: Возможна эмуляция с использованием SET_AUTH.TCP до и после передачи сообщения. Отметим неполную эквивалентность, связанную со временем подачи запроса, а не с конкретным сообщением.

Реализация с UDP: Невозможна (UDP не поддерживает аутентификации).

Запрос передачи без задержки подтверждения SACK для сообщения

Протоколы: SCTP.

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

Реализация с TCP: Ничего (TCP не предлагает такой функциональности и игнорирует такие запросы приложений, поскольку они задают сементически некорректное поведение).

Реализация с UDP: Ничего (UDP не предлагает такой функциональности и игнорирует такие запросы приложений, поскольку они задают сементически некорректное поведение).

A.2.2. Прием

Прием данных (без границ сообщений)

Протоколы: TCP.

Функционально, поскольку транспортная система должна быть способна передавать и принимать данные.

Реализация: Через RECEIVE.TCP.

Реализация с UDP: Ничего (UDP работает лишь с сообщениями и приложение может игнорировать границы).

Прием сообщения

Протоколы: SCTP, UDP(-Lite).

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

Реализация: Через RECEIVE.SCTP и RECEIVE.UDP(-Lite).

Реализация с TCP: Невозможна (TCP не указывает границы сообщений).

Выбор потока для приема

Протоколы: SCTP.

Автоматизируемо, поскольку требует множество потоков, а запрос множества потоков в категории CONNECTION.ESTABLISHMENT является автоматизируемым.

Реализация: См. параграф 5.2.

Информация о частичной доставке сообщения

Протоколы: SCTP.

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

Реализация: Через RECEIVE.SCTP.

Реализация с TCP: Ничего (эта информация недоступна в TCP).

Реализация с UDP: Ничего (эта информация недоступна в UDP).

A.2.3. Ошибки

В этом параграфе описаны отказы при передаче, связанные с конкретным вызовом категории «Передача данных» (Приложение A.2.1).

Уведомление об отказе при передаче

Протоколы: SCTP, UDP(-Lite).

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

RFC 8303 отличается от 2 указанных ниже транспортных свойств в том, что не различаются непереданные и неподтвержденные данные.

Реализация: Через SENDFAILURE-EVENT.SCTP и SEND_FAILURE.UDP(-Lite).

Реализация с TCP: Ничего (это уведомление недоступно в TCP).

Уведомление о неотправленном (частино) сообщении

Протоколы: SCTP, UDP(-Lite).

Автоматизируемо, поскольку различие между непереданными и неподтвержденными данными не связано со знанием о приложении.

Уведомление о неподтвержденном (частино) сообщении

Протоколы: SCTP.

Автоматизируемо, поскольку различие между непереданными и неподтвержденными данными не связано со знанием о приложении.

Уведомление об отсутствии в стеке данных для передачи

Протоколы: SCTP.

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

Реализация с TCP: Ничего (см. параграф 5.4).

Реализация с UDP: Ничего (это уведомление недоступно в UDP).

Уведомление получателя об отказе при частичной доставке сообщения

Протоколы: SCTP.

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

Реализация с TCP: Ничего (это уведомление недоступно в TCP).

Реализация с UDP: Ничего (это уведомление недоступно в UDP).

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

Авторы благодарят участников рабочей группы TAPS, а также исследовательских проектов NEAT и MAMI за ценный вклад в документ. Особая признательность Michael Tüxen за помощь по вопросам организации и завершения соединений, Gorry Fairhurst за предложения по части фрагментации и размера пакетов, Spencer Dawkins за очень подробную и конструктивную рецензию. Эта работа финансировалась исследовательской и инновационной программой Европейского Союза Horizon 2020 в рамках гранта 644334 (NEAT).

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

Michael Welzl

University of Oslo

PO Box 1080 Blindern

N-0316 Oslo

Norway

Phone: +47 22 85 24 20

Email: michawe@ifi.uio.no

Stein Gjessing

University of Oslo

PO Box 1080 Blindern

N-0316 Oslo

Norway

Phone: +47 22 85 24 44

Email: steing@ifi.uio.no

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

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

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Head-of-line – блокировка в начале (голове) линии.

4Stream Control Transmission Protocol – потоковый протокол управления передачей.

5Low Extra Delay Background Transport – транспорт с очень малыми задержками.

6Low Extra Delay Background Transfer – фоновая передача с очень малой задержкой.

Рубрика: RFC | Комментарии к записи RFC 8923 A Minimal Set of Transport Services for End Systems отключены

Архитектура переносимых коммутаторов P4_16 (проект)

image_print

P416 Portable Switch Architecture (PSA)

(working draft)

The P4.org Architecture Working Group

2020-10-12

PDF

Аннотация

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

Оглавление

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

1. Модель целевой архитектуры

PSA для языка P416 является аналогом стандартной библиотеки для языка программирования C. PSA определяет библиотеку типов, внешние элементы P416 (extern) для часто используемых функций (таких как счетчики, измерители и регистры), а также набор «путей пакетов» (packet path), позволяющие создавать программы P4 для управления потоками пакетов в коммутаторе с множеством портов (например, несколькими десятками портов Ethernet). Приведенные здесь API и рекомендации позволяют разработчикам создавать программы P4, переносимые между разными устройствами, соответствующими PSA.

Хотя некоторые части PSA специфичны для коммутаторов и архитектура Portable NIC Architecture (если такая будет разработана) будет существенно отличаться от PSA в этих частях, предполагается, что определенные здесь внешние элементы можно будет применять в разной архитектуре P416.

Модель PSA включает 6 программируемых блоков P4 и 2 фиксированных функциональных блока, как показано на рисунке 1. Поведение программируемых блоков задается на языке P4. Блоки PRE2 и BQE3 зависят от платформы и могут настраиваться на выполнение фиксированного набора операций.

 
Рисунок 1. Конвейер коммутатора PSA.

Входящие пакеты анализируются и проверяются на пригодность, а затем передаются во входной конвейер СД (сопоставление-действие, match-action), принимающий решение о дальнейшем пути пакетов. Входной сборщик (deparser) P4 задает содержимое пакета, отправляемое в буфер, и сопровождающие пакет метаданные. После входного конвейера пакет может быть реплицирован (т. е. созданы копии для нескольких выходных портов), а затем сохранен в буфере.

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

Разработчик программы для PSA должен определить объекты в программируемых блоках P4, которые соответствуют определенным ниже API (5. Программируемые блоки). Для входных и выходных данных программируемых блоков применяются шаблоны заданных в программе заголовков и метаданных. После определения 6 программируемых блоков программа P4 для архитектуры PSA создает основной объект (пакет, package) с программируемыми блоками в качестве аргументов (см. например, 7.3. Блок репликации пакетов).

Для повышения уровня переносимости программы P4 следует выполнять приведенные ниже рекомендации:

  • не использовать неопределенных значений, которые могут влиять на выходные пакеты или иметь побочное влияние на счетчики, измерители или регистры;
  • использовать как можно меньше ресурсов, таких как размер ключей поиска, размер массивов, объем связанных с пакетом метаданных и т. п.

В этом документе приведены фрагменты нескольких программ P416, использующих включаемый файл psa.p4 и демонстрирующих возможности PSA. Исходный код этих программ доступен в репозитории, содержащем официальную спецификацию.

2. Соглашения об именах

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

  • Имена типов используют «стиль верблюда» (CamelCase) и суффикс _t. Например, PortId_t.
  • Типы элементов управления (control) и внешних объектов (extern) именуются в стиле CamelCase. Например, IngressParser.
  • Структурные типы именуются с использованием символов нижнего регистра, разделителей _ и суффикса _t. Например, psa_ingress_input_metadata_t.
  • Имена действий, внешних методов и функций, заголовков, структур и экземпляров элементов управления начинаются с символа нижнего регистра и используют разделители слов _. Например, send_to_port.
  • Перечисляемые элементы, определения констант и константы #define именуются с использованием символов верхнего регистра и разделителей _. Например, PSA_PORT_CPU.

Для зависимых от архитектуры метаданных (например, структур) используется префикс psa_.

3. Пути пакетов

На рисунке 2 показаны все возможные пути для пакетов, которые должна поддерживать реализация PSA. Кроме того, реализация может поддерживать дополнительные пути, не описанные здесь.

 
Рисунок 2. Пути пакетов в PSA.

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

Таблица 1. Именование путей пакетов в коммутаторе.

Обозначение

Описание

Источник

Получатель

NFP

Обычный пакет из порта

Порт

Входной анализатор

NFCPU

Пакет из порта CPU

Порт CPU

Входной анализатор

NU

Обычный индивидуальный пакет из входного конвейера в выходной

Входной сборщик

Выходной анализатор

NM

Обычный реплицированный групповой пакет из входного конвейера в выходной

Выходной сборщик с помощью PRE

Входной анализатор (возможно несколько копий)

NTP

Обычный пакет в порт

Выходной сборщик

Порт

NTCPU

Обычный пакет в порт CPU

Выходной сборщик

Порт CPU

RESUB

Повторно представленный пакет

Входной сборщик

Входной анализатор

CI2E

Клон пакета из входного конвейера в выходной

Входной сборщик

Выходной анализатор

RECIRC

Рециркулированный пакет

Выходной сборщик

Входной анализатор

CE2E

Клон из выходного конвейера в него же

Выходной сборщик

Выходной анализатор

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

Таблица 2. Результаты однократной обработки пакетов во входном и выходном конвейере.

Обозначение

Описание

Дальнейшая обработка

Результирующие пакеты

NFP

Обычный пакет из порта

Входной конвейер

Не более 1 пакета CI2E, плюс не более 1 пакета RESUB, NU или NM. См. параграф 6.2. Поведение пакетов по завершении входной обработки.

NFCPU

Пакет из порта CPU

RESUB

Повторно представленный пакет

RECIRC

Рециркулированный пакет

NU

Обычный индивидуальный пакет из входного конвейера в выходной

Выходной конвейер

Не более 1 пакета CE2E, плюс не более 1 пакета RECIRC, NTP или NTCPU. См. параграф 6.5. Поведение пакетов по завершении выходной обработки.

NM

Обычный реплицированный групповой пакет из входного конвейера в выходной

CI2E

Клон пакета из входного конвейера в выходной

CE2E

Клон из выходного конвейера в него же

NTP

Обычный пакет в порт

Устройство на другой стороне

Определяется другим устройством

NTCPU

Обычный пакет в порт CPU

CPU

Определяется CPU

В PSA имеются поля метаданных, позволяющие программам P4 указать путь, по которому проходит каждый пакет, и следующий элемент управления для каждого пакета (см. раздел 6. Описание путей пакетов).

Для выходных пакетов выбор одного из выходных портов, порта CPU или порта рециркуляции выполняется предшествующим непосредственно этапом обработки (входной конвейер для NU, NM и CI2E, выходной конвейер для CE2E). При выходной обработке может быть принято решение об отбрасывании пакета вместо его передачи в выбранный ранее порт, но невозможно изменить выходной порт. Выбор выходного порта (или портов) обычно происходит во входном конвейере программы P4. Единственным исключением является выбор выходного порта для клонов CE2E, создаваемых непосредственно предшествующим этапом обработки. Причины этого исключения рассмотрены в приложении D.2. Неизменность выходного порта в процессе выходной обработки.

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

  • Исходный пакет принимается как NFP через порт 2. Входная обработка создает клон CI2E, адресованный в порт CPU (копия 1), и групповой пакет NM для multicast-группы 18, которая настроена в PacketReplicationEngine на создание копий для порта 5 (копия 2) и порта рециркуляции PSA_PORT_RECIRCULATE (копия 3).
  • Для копии 1 выполняется выходная обработка с передачей пакета по пути NTCPU в порт CPU.
  • Для копии 2 выполняется выходная обработка, которая создает клон CE2E для порта 8 (копия 4) и передает пакет NTP в порт 5.
  • Для копии 3 выполняется выходная обработка, которая возвращает RECIRC обратно на вход (копия 5).
  • Для копии 4 выполняется выходная обработка, передающая пакет NTP в порт 8.
  • Для копии 5 выполняется входная обработка, передающая пакет NU, направленный в порт 1 (копия 6).
  • Для копии 6 выполняется выходная обработка, которая отбрасывает пакет вместо передачи в порт 1.

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

В PSA нет обязательного механизма для предотвращения создания из одного полученного пакета пакетов, порождающих бесконечную бесконечную рециркуляцию, повторное представление или клонирование CE2E. Такое поведение можно предотвратить тестированием программ P4 и/или включением в программу P4 метаданных «времени жизни», передаваемых с копиями пакетов подобно полю TTL в заголовках IPv4.

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

4. Типы данных PSA

4.1. Определения типов PSA

Каждая реализация PSA имеет конкретный размер в битах для описанных ниже типов в плоскости данных. Значения размера определяются во включаемом файле psa.p4 для конкретной платформы. Предполагается, что в разных реализациях PSA могут применяться разные размеры4.

Для каждого из этих типов интерфейс P4 Runtime API5 может использовать независимые от платформы размеры, которые определяются спецификацией P4 Runtime API, однако предполагается, что эти размеры будут не меньше соответствующих типов InHeader_t, перечисленных ниже, чтобы их можно было применять с любой платформой. Все реализации PSA должны применять в плоскости данных размеры типов, не превышающие соответствующий размер определенных типов InHeader_t.

/* В определениях применяется typedef, а не type, поэтому они просто
* задают другие имена для типа bit<W> с конкретным значением W. 
* В отличие от приведенных ниже определений type, значения, объявленные
* с именами типов typedef можно свободно перемешивать в выражениях как
* и другие щначения, объявленные с типом bit<W>. Приведенные ниже
* имена с type нельзя свободно перемешивать, если они не были сначала
* приведены к соответствующему типу typedef. Хотя это может оказаться
* неудобным при работе с арифметическими выражениями, такой подход 
* позволяет отметить все значения типов type в создаваемом автоматически
* API плоскости управления.
*
* Отметим, что размер typedef <name>Uint_t всегда совпадает с размером
* type <name>_t. */
typedef bit<unspecified> PortIdUint_t;
typedef bit<unspecified> MulticastGroupUint_t;
typedef bit<unspecified> CloneSessionIdUint_t;
typedef bit<unspecified> ClassOfServiceUint_t;
typedef bit<unspecified> PacketLengthUint_t;
typedef bit<unspecified> EgressInstanceUint_t;
typedef bit<unspecified> TimestampUint_t;
@p4runtime_translation("p4.org/psa/v1/PortId_t", 32)
type PortIdUint_t	PortId_t;
@p4runtime_translation("p4.org/psa/v1/MulticastGroup_t", 32)
type MulticastGroupUint_t 	MulticastGroup_t;
@p4runtime_translation("p4.org/psa/v1/CloneSessionId_t", 16)
type CloneSessionIdUint_t 	CloneSessionId_t;
@p4runtime_translation("p4.org/psa/v1/ClassOfService_t", 8)
type ClassOfServiceUint_t 	ClassOfService_t;
@p4runtime_translation("p4.org/psa/v1/PacketLength_t", 16)
type PacketLengthUint_t	PacketLength_t;
@p4runtime_translation("p4.org/psa/v1/EgressInstance_t", 16)
type EgressInstanceUint_t 	EgressInstance_t;
@p4runtime_translation("p4.org/psa/v1/Timestamp_t", 64)
type TimestampUint_t	Timestamp_t;
typedef error	ParserError_t;

const PortId_t PSA_PORT_RECIRCULATE = (PortId_t) unspecified;
const PortId_t PSA_PORT_CPU = (PortId_t) unspecified;
const CloneSessionId_t PSA_CLONE_SESSION_TO_CPU = (CloneSessiontId_t) unspecified;
/* Примечание. Все типы с InHeader в именах предназначены лишь для значений
* соответствующих типов в заголовках пакетов между устройством PSA и сервером
* P4Runtime, который управляет им.
*
* Указанные здесь размеры должны быть не меньше, чем будет применять 
* для этого типа любое из устройств PSA. Таким образом эти типы могут
* быть полезны для определения пакетов, передаваемых устройством PSA
* напрямую другим устройствам без прохождения через сервер P4Runtime
* (например, при отправке пакетов контроллеру или системе сбора данных
* на скоростях, превышающих возможности сервера P4Runtime). В таких
* случаях не требуется автоматического преобразования этих типов
* плоскостью данных PSA как при передаче серверу P4Runtime. Все такие
* преобразования следует включать в программу P4.
*
* Все размеры должны быть кратны 8, чтобы любое подмножество этих полей
* можно было использовать в одном определении заголовка P4 даже в случаях, 
* когда реализации P4 требуют от содержащего поля заголовка кратный 8
* битам размер. */
/* Причины использования typedef описаны выше. */
typedef bit<32> 	PortIdInHeaderUint_t;
typedef bit<32> 	MulticastGroupInHeaderUint_t;
typedef bit<16> 	CloneSessionIdInHeaderUint_t;
typedef bit<8> 	ClassOfServiceInHeaderUint_t;
typedef bit<16> 	PacketLengthInHeaderUint_t;
typedef bit<16> 	EgressInstanceInHeaderUint_t;
typedef bit<64> 	TimestampInHeaderUint_t;
@p4runtime_translation("p4.org/psa/v1/PortIdInHeader_t", 32)
type PortIdInHeaderUint_t		PortIdInHeader_t;
@p4runtime_translation("p4.org/psa/v1/MulticastGroupInHeader_t", 32)
type MulticastGroupInHeaderUint_t 	MulticastGroupInHeader_t;
@p4runtime_translation("p4.org/psa/v1/CloneSessionIdInHeader_t", 16)
type CloneSessionIdInHeaderUint_t 	CloneSessionIdInHeader_t;
@p4runtime_translation("p4.org/psa/v1/ClassOfServiceInHeader_t", 8)
type ClassOfServiceInHeaderUint_t 	ClassOfServiceInHeader_t;
@p4runtime_translation("p4.org/psa/v1/PacketLengthInHeader_t", 16)
type PacketLengthInHeaderUint_t	PacketLengthInHeader_t;
@p4runtime_translation("p4.org/psa/v1/EgressInstanceInHeader_t", 16)
type EgressInstanceInHeaderUint_t 	EgressInstanceInHeader_t;
@p4runtime_translation("p4.org/psa/v1/TimestampInHeader_t", 64)
type TimestampInHeaderUint_t		TimestampInHeader_t;

4.2. Поддерживаемые PSA типы метаданных

enum PSA_PacketPath_t {
	NORMAL,	/// Полученный входным конвейером пакет, не относящийся к приведенным ниже.
	NORMAL_UNICAST,	/// Обычный индивидуальный пакет, полученный выходным конвейером.
	NORMAL_MULTICAST,	/// Обычный групповой пакет, полученный выходным конвейером.
	CLONE_I2E,	/// Пакет, созданный операцией clone во входном конвейере и 
			/// предназначенный для выходного конвейера.
	CLONE_E2E, 	/// Пакет, созданный операцией clone в выходном конвейере и 
			/// предназначенный для выходного конвейера.
	RESUBMIT,	/// Пакет, полученный в результате операции resubmit.
	RECIRCULATE 	/// Пакет, полученный в результате операции recirculate.
}

struct psa_ingress_parser_input_metadata_t {
	PortId_t		ingress_port;
	PSA_PacketPath_t	packet_path;
}

struct psa_egress_parser_input_metadata_t {
	PortId_t		egress_port;
	PSA_PacketPath_t	packet_path;
}

struct psa_ingress_input_metadata_t {
	// Все перечисленные значения инициализируются архитектурой до
	// начала выполнения блока управления Ingress.
	PortId_t		ingress_port;
	PSA_PacketPath_t	packet_path;
	Timestamp_t		ingress_timestamp;
	ParserError_t		parser_error;
}

struct psa_ingress_output_metadata_t {
	// В комментариях после полей указаны исходные значения на момент
	// начала выполнения блока управления Ingress.
	ClassOfService_t	class_of_service; 	// 0
	bool			clone;			// false
	CloneSessionId_t	clone_session_id;	// не определено
	bool			drop;			// true
	bool			resubmit;		// false
	MulticastGroup_t	multicast_group; 	// 0
	PortId_t		egress_port;		// не определено

struct psa_egress_input_metadata_t {
	ClassOfService_t	class_of_service;
	PortId_t		egress_port;
	PSA_PacketPath_t	packet_path;
	EgressInstance_t	instance;	/// экземпляр от PacketReplicationEngine
	Timestamp_t		egress_timestamp;
	ParserError_t		parser_error;
}

/// Эта структура является входным (in) параметром выходного сборщика. 
/// Она включает достаточно данных, чтобы сборщик мог решить вопрос о
/// рециркуляции пакета.
struct psa_egress_deparser_input_metadata_t {
	PortId_t	egress_port;
}

struct psa_egress_output_metadata_t {
	// В комментариях после полей указаны исходные значения на момент
	// начала выполнения блока управления Egress.
	bool			clone;			// false
	CloneSessionId_t	clone_session_id; 	// не определено
	bool			drop;			// false
}

4.3. Типы сопоставления

PSA поддерживает дополнительные типы match_kind сверх 3, определенных в спецификации P416.

match_kind {
	range,		/// Служит для представления интервалов min-max.
	selector 	/// Служит для динамического выбора действий с 
			/// помощью внешнего блока ActionSelector.
}

Тип selector поддерживается только для таблиц в реализацией селектора действий (7.12. Селекторы действий).

4.3.1. Таблицы range

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

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

В таблицах range могут присутствовать поля lpm. В таких случаях для выбора записи применяется длина префикса, но при наличии нескольких совпадающих записей размер префикса не определяет их относительный приоритет и применяются лишь значения приоритета, заданные плоскостью управления. Если в таблице range имеются записи, заданные с помощью свойства записи const, относительный приоритет записей определяется по порядку их размещения в программе P4 (первая запись имеет наибольший приоритет).

4.3.2. Таблицы ternary

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

4.3.3. Таблицы lpm

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

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

4.3.4. Таблицы exact

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

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

Реализации плоскости данных PSA, поддерживающие P4 Runtime API6, включают программу P4 Runtime Server, которая позволяет программировать устройство PSA в процессе работы с помощью одного или множества P4 Runtime Client. Для краткости P4 Runtime Server будет называть агентом, а P4 Runtime Client – контроллером. Контроллер может управлять множеством устройств с разными реализациями PSA.

Как отмечено в параграфе 4.1. Определения типов PSA, предполагается, что разные реализации PSA могут задавать размеры типов данных, которые напрямую связаны с объектами плоскости данных, например, портами, идентификаторами multicast-групп и т. п..

Предполагается, что некоторые реализации PSA будут использовать заметно меньше ресурсов для таких объектов как ключи таблиц и параметры действий, если плоскость данных сохраняет лишь небольшое число битов, требуемое для значений каждого типа. Например, реализация может определять PortId_t как bit<6> вместо bit<16> и сберечь за счет этого 10 Мбит хранилища при миллионе записей в таблице7.

P4 Runtime API использует величины, битовый размер которых не зависит от целевой платформы, для типов, указанных в параграфе 4.1. Определения типов PSA, с целью упрощения работы с этими типами в программах агента и контроллера. Для операций плоскости управления с таблицами поиска все операции отсечки или дополнения полей выполняются агентом (обычно отсечка выполняется при передаче от контроллера к устройству, а дополнение – при передаче от устройства в контроллер).

Имеется множество вариантов обмена такими типами между контроллером и плоскостью данных.

  • Операции плоскости управления над таблицами, где значения этих типов могут включаться как параметры действий или ключи.
  • Операции плоскости управления по анализу наборов значений где эти типы могут быть частью ключа.
  • Пакеты, передаваемые CPU (входные с точки зрения контроллера) или получаемые от него (выходные).
  • Поля в уведомлениях внешнего блока Digest (7.14. Дайджест пакета).
  • Поля данных в массиве Register (7.9. Регистры).

Отметим, что приведенный список не является исчерпывающим.

Для пакетов между плоскостью управления и устройством PSA существует проблема, связанная с тем, что многие реализации PSA могут ограничивать в программах P4 размеры полей заголовков кратными 8 битам значениями. Чтобы соблюсти это ограничение и позволить определение типов заголовков P4 с полями специфичных для PSA типов, совместимыми с разными реализациями PSA, были определены дополнительные типы, содержащие в именах InHeader. Например, PortIdInHeader_t подобен PortId_t, но должен иметь размер, кратный 8 битам и не меньше размера PortId_t.

Поскольку эти типы InHeader имеют кратный 8 битам размер, можно включать любую их комбинацию в определение типа заголовка P4, коль скоро другие поля заголовка имеют размер, кратный 8 битам. Контроллеру или программе P4, генерирующим пакеты с такими заголовками, следует заполнять старшие биты полей нулями. Это можно делать с помощью обычных операторов присваивания в программе P4 с приведением правой части к размеру InHeader. Обратное приведение более длинного значения (например, PortIdInHeader_t к PortId_t) выполняется путем отсечки старших битов.

Значения типа PortId_t имеют в реализациях PSA необычное свойство. Поскольку это может упростить некоторые аппаратные реализации, численные значения полей типа PortId_t в плоскости данных P4 могут не быть простыми диапазонами (например, 0 – 31, как можно было бы задать в программе плоскости управления для 32-портового устройства). Предполагается, что агент будет преобразовывать численные идентификаторы портов в контроллере идентификаторы портов плоскости данных и обратно для каждого из описанных выше каналов взаимодействия между контроллером и плоскостью данных. Файл psa.p4 содержит аннотацию p4runtime_translation для определений типов PortId_t и PortIdInHeader_t. Это позволяет компилятору отметить все случаи применения значений этих типов, доступные из P4Runtime API, чтобы программы агента знали о необходимости преобразования идентификаторов. Это позволяет не указывать специально все случаи использования этих типов в программе P4.

Такой подход требует явного приведения типов к bit<W> для выполнения арифметических операций. Включаемый файл psa.p4 определяет PortIdUint_t как typedef с таким же размером, как type PortId_t, что позволяет привести значения типа PortId_t к типу PortIdUint_t, а затем выполнить с ними арифметические операции P4. Результат нужно явно привести обратно к типу PortId_t, если его нужно передать в поле метаданных этого типа. Соответствующие типы с Uint в именах определены для всех типов PSA. Из-за этого преобразования рекомендуется трактовать значения типа PortId_t как значения перечисляемого типа (enum). Сравнение двух значений этого типа на равенство или неравенство допустимо, также как присваивание значений другим переменным или параметрам того же типа, но почти все прочие операции ведут к ошибкам. При сопоставлении значения типа PortId_t как части ключа таблицы, нужно всегда проверять точное или шаблонное совпадение для каждого бита значения (т. е. сопоставление ternary с шаблоном для всех битов или lpm с префиксом нулевого размера). При попытке выполнить любое из указанных ниже действий со значением типа PortId_t или PortIdInHeader_t численное преобразование приведет к ошибкам в программе.

  • Сопоставление ключа с подмножеством битов или диапазоном.
  • Сопоставление номера порта с использованием оператора сравнения < или >.
  • Сравнение номера порта с конкретными литеральными значениями (например, 0 или 0xff). Вместо этого рекомендуется сравнивать такие значения, используя их как поля ключа поиска в таблице или поля ключа набора значений анализатора, со значениями, установленными плоскостью управления (которые транслируются в соответствующие значения для устройства программой агента плоскости управления). Разумно также сравнивать значения портов с символьными константами PSA_PORT_CPU или PSA_PORT_RECIRCULATE, которые имеют конкретные числовые значения для платформы.
  • Выполнение арифметических операций для значения с намерением получить значения, соответствующее другому порту устройства. Некоторые числовые значения могут не соответствовать ни одному из портов устройства и номера портов не обязаны быть последовательными.

Приведенный выше список не является исчерпывающим.

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

  • PortId_t или PortIdInHeader_t;
  • ClassOfService_t или ClassOfServiceInHeader_t;

Для перечисленных ниже типов по умолчанию численные преобразования не происходят8. Плоскость данных PSA должна поддерживать все численные значения от 0 до своего максимума. За исключением Timestamp_t число поддерживаемых плоскостью данных не обязано быть степенью 2. Контроллеры должны иметь способ определения максимального значения, поддерживаемого устройством PSA для каждого из этих типов.

  • MulticastGroup_t – 0 является особым значением, указывающим отсутствие групповой репликации для пакета, поэтому данный тип является исключением из указанного выше правила поддержки плоскостью управления значения 0.

  • CloneSessionId_t.

  • PacketLength_t.

  • EgressInstance_t.

  • Timestamp_t9

Отметим, что для всех этих типов имеются аннотации p4runtime_translation во включаемом файле psa.p4, чтобы при генерации компилятором файла P4Runtime P4Info из исходной программы в этот файл были включены типы, указанные p4runtime_translation, вместо зависимых от платформы размеров типа. Для одной программы P4 содержимое P4Info должно совпадать для всех платформ.

Если размер типа, указанный в качестве второго параметра p4runtime_translation, отличается от размера для платформы (или базового типа), предполагается, что сервер P4Runtime выполнит подходящее приведение типа. Кроме того, в процессе работы могут быть включены более сложные численные преобразования для любого типа, аннотированного в p4runtime_translation, хотя произвольные преобразования обязательны лишь для PortId_t, ClassOfService_t и других вариантов InHeader. Чтобы выполнить произвольное числовое преобразование для заданного типа, система P4Runtime ожидает URI (первый параметр p4runtime_translation) и нужного отображения.

5. Программируемые блоки

Ниже приведены шаблоны объявления программируемых блоков PSA. Разработчик программы P4 отвечает за реализацию элементов управления, соответствующих этим интерфейсам, и создание их экземпляров в определении пакета (package). Здесь используются одни пользовательские типы метаданных IM и заголовков IH для всех входных анализаторов и блоков управления. Выходной анализатор и блоки управления могут те же или иные типы по усмотренияю разработчика программы P4.

parser IngressParser<H, M, RESUBM, RECIRCM>(
	packet_in buffer,
	out H parsed_hdr,
	inout M user_meta,
	in psa_ingress_parser_input_metadata_t istd,
	in RESUBM resubmit_meta,
	in RECIRCM recirculate_meta);

control Ingress<H, M>(
	inout H hdr, inout M user_meta,
	in psa_ingress_input_metadata_t istd,
	inout psa_ingress_output_metadata_t ostd);

control IngressDeparser<H, M, CI2EM, RESUBM, NM>(
	packet_out buffer,
	out CI2EM clone_i2e_meta,
	out RESUBM resubmit_meta,
	out NM normal_meta,
	inout H hdr,
	in M meta,
	in psa_ingress_output_metadata_t istd);

parser EgressParser<H, M, NM, CI2EM, CE2EM>(
	packet_in buffer,
	out H parsed_hdr,
	inout M user_meta,
	in psa_egress_parser_input_metadata_t istd,
	in NM normal_meta,
	in CI2EM clone_i2e_meta,
	in CE2EM clone_e2e_meta);

control Egress<H, M>(
	inout H hdr, inout M user_meta,
	in psa_egress_input_metadata_t istd,
	inout psa_egress_output_metadata_t ostd);

control EgressDeparser<H, M, CE2EM, RECIRCM>(
	packet_out buffer,
	out CE2EM clone_e2e_meta,
	out RECIRCM recirculate_meta,
	inout H hdr,
	in M meta,
	in psa_egress_output_metadata_t istd,
	in psa_egress_deparser_input_metadata_t edstd);
package IngressPipeline<IH, IM, NM, CI2EM, RESUBM, RECIRCM>(
	IngressParser<IH, IM, RESUBM, RECIRCM> ip,
	Ingress<IH, IM> ig,
	IngressDeparser<IH, IM, CI2EM, RESUBM, NM> id);

package EgressPipeline<EH, EM, NM, CI2EM, CE2EM, RECIRCM>(
	EgressParser<EH, EM, NM, CI2EM, CE2EM> ep,
	Egress<EH, EM> eg,
	EgressDeparser<EH, EM, CE2EM, RECIRCM> ed);

package PSA_Switch<IH, IM, EH, EM, NM, CI2EM, CE2EM, RESUBM, RECIRCM> (
	IngressPipeline<IH, IM, NM, CI2EM, RESUBM, RECIRCM> ingress,
	PacketReplicationEngine pre,
	EgressPipeline<EH, EM, NM, CI2EM, CE2EM, RECIRCM> egress,
	BufferingQueueingEngine bqe);

6. Описание путей пакетов

В разделе 3. Пути пакетов кратко перечислены пути пакетов, предоставляемые PSA и указаны их сокращенные имена, применяемые здесь.

6.1. Начальные значения пакетов, обрабатываемых входным конвейером

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

6.1.1. Исходное содержимое пакетов из портов

Для пакетов Ethernet поле packet_in пакетов в путях FP и NFCPU содержит кадр Ethernet, начиная с заголовка Ethernet Контрольная сумма (CRC) кадра Ethernet не включается10.

Таблица 3. Начальные значения для пакетов, обрабатываемых входным конвейером.

NFP

NFCPU

RESUB

RECIRC

packet_in

См. текст

user_meta

См. текст

Поля IngressParser istd (тип psa_ingress_parser_input_metadata_t)

ingress_port

Значение PortId_t входного порта для пакета

PSA_PORT_CPU

Копируется из повторно представленного пакета

PSA_PORT_RECIRCULATE

packet_path

NORMAL

NORMAL

RESUBMIT

RECIRCULATE

Входные поля istd (тип psa_ingress_input_metadata_t)

ingress_port

То же значение, которое получено IngressParser (см. выше).

packet_path

То же значение, которое получено IngressParser (см. выше).

ingress_timestamp

Время начала обработки пакета в IngressParser. Для пакетов RESUB и RECIRC это время начала обработки «копии», а не оригинала.

parser_error

От IngressParser. Всегда error.NoError, если при анализе не возникло ошибок.

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

В P4 Runtime имеется свойство Packet Out для отправки пакетов данных из контроллера в устройство PSA. Такие пакеты передаются в PSA как пакеты пути NFCPU. С этими пакетами не связано метаданных и они включают лишь содержимое, которое обрабатывается кодом IngressParser в программе P4 обычным способом. При этом может выполняться приведение типов полей заголовка, как описано в параграфе 4.4. Представление данных в плоскости управления и данных.

6.1.2. Исходное содержимое повторно представленных пакетов

Для пакетов RESUB в packet_in содержится то же, что и в packet_in до IngressParser для пакета, вызвавшего повторное представление данного пакета (т. е. без изменений, внесенных при входной обработке).

6.1.3. Исходное содержимое рециркулирующих пакетов

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

6.1.4. Пользовательские метаданные для всех входных пакетов

Архитектура PSA не требует инициализации пользовательских метаданных известными значениями перед отправкой пакета входному анализатору. Если пользовательская программа P4 явно инициализирует такие метаданные заранее (например, при старте анализатора), они будут проходить через анализатор в блок управления Ingress.

Имеется два направления в параметрах входного анализатора с пользовательскими типами – resubmit_meta и recirculate_meta. Они могут применяться для передачи метаданных в повтроно представляемых и рециркулированных пакетах.

Рассмотрим пакет, приходящий во входной конвейер и получающий в процессе обработки программой P4 значения стандартных полей метаданных PSA, приводящие к повторному представлению пакета (6.2. Поведение пакетов по завершении входной обработки). Во входном сборщике программа P4 задает значение выходного параметра resubmit_meta. Это значение (оно может содержать набор полей, структур, заголовков и т. п.) связывается реализацией PSA с повторно представляемым пакетом many individual values in fields, sub-structs, headers, etc.) becomes associated with the resubmitted packet by the PSA и при входном анализе повторно представленного пакета становится значением входного параметра resubmit_meta для входного анализатора. Для повторно представленных пакетов значение входного параметра recirculate_meta не определено.

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

Для пакетов из порта (включая CPU) входные параметры resubmit_meta и recirculate_meta не определены.

6.2. Поведение пакетов по завершении входной обработки

Приведенный ниже псевдокод управляет копированием (клонированием) пакетов по завершении работы блока управления Ingress на основе значений полей некоторых метаданных в структуре psa_ingress_output_metadata_t. Отмеченная ниже функция platform_port_valid() принимает значение типа PortId_t и возвращает, если это значение представляет выходной порт для реализации. Предполагается, что в некоторых реализациях PSA будут применяться битовые маски для значений PortId_t, не соответствующих какому-либо порту. Функция возвращает значение true для портов PSA_PORT_CPU и PSA_PORT_RECIRCULATE. Функция platform_port_valid не определена в PSA для вызова из программы P4 плоскости данных, поскольку нет известных вариантов ее вызова во время обработки пакета. Она предназначена для описания поведения в псевдокоде. Предполагается, что плоскость данных создает таблицы с действительными номерами портов.

Комментарии «рекомендовано для записи ошибок» не являются требованием и служат рекомендацией поддерживать в реализации PSA счетчики для таких ошибок. Полезно также записывать более подробные сведения о нескольких первых ошибках, например, очередь FIFO для первых недействительных значений, вызвавших ошибку, а также другую информацию, о вызвавших ошибки пакетах. Программы плоскости управления или драйвер смогут считывать эти сведения, а также считывать и очищать очереди FIFO, чтобы помочь разработчикам P4 при отладке кода.

struct psa_ingress_output_metadata_t {
	// В комментарии после каждого поля указано значение в момент
	// начала выполнения блока управления Ingress.
	ClassOfService_t	class_of_service;	// 0
	bool			clone;			// false
	CloneSessionId_t	clone_session_id; 	// не определено
	bool			drop;			// true
	bool			resubmit;		// false
	MulticastGroup_t	multicast_group; 	// 0
	PortId_t		egress_port;		// не определено
}

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

psa_ingress_output_metadata_t ostd;

if (ostd.clone) {
	Создается клон(ы) I2E с опциями, настроенными сеансом клонирования 
	PRE с номером ostd.clone_session_id;
} else { нет клонирования; }

if (ostd.drop) { отбрасывание пакета; }
else if (ostd.resubmit) { повторное представление пакета; }
else if (ostd.multicast_group != 0) { PRE multicast реплицирует пакет; }
else { PRE передает 1 копию пакета в ostd.egress_port; }

Приведенный ниже псевдокод определяет поведение, которому должна следовать реализация PSA.

psa_ingress_output_metadata_t ostd;
if (ostd.clone) {
	if (значение ostd.clone_session_id поддерживается) {
		из значений, настроенных для ostd.clone_session_id в PRE {
			cos = class_of_service
			set((egress_port[0], instance[0]), ..., (egress_port[n], instance[n])) =
				набор пар egress_port и instance
			trunc = truncate
			plen = packet_length_bytes
		}
		if (значение cos не поддерживается) {
			cos = 0;
			// рекомендуется записать ошибку (не поддерживается значение cos).
		}
		Для каждой пары (egress_port, instance) в наборе {
			Создается клон пакета и передается в буфер пакетов с 
			egress_port, instance и class_of_service cos, после
			чего начинается выходная обработка. Клон будет включать 
			лишь первые plen байтов пакета, полученного входным
			анализатором, если trunc = true, и целый пакет в противном случае.
		}
	} else {
		// Клон не создается. Рекомендуется записать ошибку, связанную с 
		// не поддерживаемым значением ostd.clone_session_id.
	}
}
// Продолжение независимо от создания клона. Приведенный ниже код не оказывает
// влияния на созданные клоны.
if (ostd.drop) {
	Пакет отбрасывается.
	return;	// Последующие операции не выполняются.
}
if (значение ostd.class_of_service не поддерживается) {
	ostd.class_of_service = 0;	// Используется принятый по умолчанию класс 0
	// Рекомендуется записать ошибку, связанную с не поддерживаемым
	// значением ostd.class_of_service.
}
if (ostd.resubmit) {
	Пакет представляется повторно, возвращаясь во входной анализатор;
	return;	// Последующие операции не выполняются.
}
if (ostd.multicast_group != 0) {
	Могут создаваться копии пакета в соответствии с конфигурацией
	плоскости управления для multicast-группы ostd.multicast_group.
	Каждая копия будут иметь одинаковое значение ostd.class_of_service.
	return;	// Последующие операции не выполняются.
}
if (platform_port_valid(ostd.egress_port)) {
	Пакет помещается в очередь для выходного порта ostd.egress_port с классом
	обслуживания ostd.class_of_service.
} else {
	Пакет отбрасывается.
	// рекомендуется записать ошибку, связанную с не поддерживаемым ostd.egress_port.
}

Всякий раз, когда приведенный выше псевдокод направляет пакет по тому или иному пути, реализация PSA может при некоторых обстоятельствах отбросить пакет вместо его передачи. Например, причиной может служить нехватка буферов или какой-либо из механизмов контроля перегрузки, таких как RED11 или AFD12. Реализациям рекомендуется поддерживать счетчики отброшенных пакетов, предпочтительно раздельные для разных причин отбрасывания, поскольку некоторые из этих причин лежат за пределами ответственности программы P4.

Реализация PSA может поддерживать множество классов обслуживания для пакетов, передаваемых в буфер. В таких случаях блок управления Ingress может назначить для поля ostd.class_of_service значение, отличное от принятого по умолчанию (0).

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

Спецификация P4 Runtime API определяет для контроллера способы определения числа различных классов обслуживания, поддерживаемых устройством PSA.

6.2.1. Групповая репликация

Плоскость управления может настроить для каждой группы multicast_group в PRE создание нужного числа копий для передачи в эту группу. Изначально каждая группа пуста и передача пакета в пустую группу ведет к его отбрасыванию. Плоскость управления может добавлять в группу одну или множество пар (egress_port, instance), а также может удалять имеющиеся пары из группы.

Предположим, что multicast-группа содержит приведенный ниже набор пар.

(egress_port[0], instance[0]),
(egress_port[1], instance[1]),
...,
(egress_port[N-1], instance[N-1])

При отправке пакета в эту группу создается N копий пакета. Копия с номером i, переданная на выходную обработку, будет иметь структуру типа psa_egress_input_metadata_t с полями egress_port = egress_port[i] и instance = instance[i].

Примечание. Группа представляет собой набор пар и от реализации не требуется создавать копии в порядке, который может задать плоскость управления. Рекомендации по упорядочению пакетов в устройствах PSA приведены в Приложении F. Упорядочение пакетов.

В одной multicast-группе все пары (egress_port, instance) должны отличаться друг от друга, но разрешено иметь совпадающее значение egress_port или instance в любом количестве пар. Любая пара (egress_port, instance) может входить в произвольное число multicast-групп.

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

Устройство PSA должно поддерживать для egress_port в группах значения PSA_PORT_CPU и PSA_PORT_RECIRCULATE. Копии групповых пакетов, созданные для этих портов будут вести себя при выходной обработке как обычные индивидуальные пакеты для соответствующего порта (т. е., не будучи отброшенными, попадут в порт CPU или рециркулируются на вход).

6.3. Действия по направлению пакетов при входной обработке

Все описанные ниже действия меняют одно или несколько полей в структуре типа psa_ingress_output_metadata_t, которая является параметром inout для блока управления Ingress, и не оказывают иных непосредственных влияний. Судьба пакетов определяется значениями всех полей структуры по завершении входной обработки, а не в момент выполнения действий (см. параграф 6.2. Поведение пакетов по завершении входной обработки).

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

6.3.1. Индивидуальные операции

Отправка пакета в порт. Значения полей в начале выходной обработки пакета показаны в столбце NU таблицы 4.

/// Изменяются выходные метаданные входной обработки для отправки 
/// пакета на выходную обработку, а затем в egress_port (в процессе
/// выходной обработки пакет может быть отброшен). Это действие не 
/// влияет на операции клонирования и повторного представления.
action send_to_port(inout psa_ingress_output_metadata_t meta,
		     in PortId_t egress_port)
{
	meta.drop = false;
	meta.multicast_group = (MulticastGroup_t) 0;
	meta.egress_port = egress_port;
}

6.3.2. Групповые операции

Отправки пакета в multicast-группу или порт. Значения полей в начале выходной обработки пакета показаны в столбце NM таблицы 4.

Параметр multicast_group является идентификатором multicast-группы. Плоскость управления должна настраивать multicast-группы с помощью специального механизма, например, P4 Runtime API.

/// Изменение выходных метаданных входной обработки для создания копий
/// пакета, передаваемых на выходную обработку. Это действие не влияет
/// на операции клонирования и повторного представления.
action multicast(inout psa_ingress_output_metadata_t meta,
		  in MulticastGroup_t multicast_group)
{
	meta.drop = false;
	meta.multicast_group = multicast_group;
}

6.3.3. Отбрасывание пакета

Пакет не передается на обычную выходную обработку.

/// Изменение выходных метаданных входной обработки для отмены
/// обычной выходной обработки. Это действие не влияет на
/// клонирование пакетов, но предотвращает повторное представление.
action ingress_drop(inout psa_ingress_output_metadata_t meta)
{
	meta.drop = true;
}

6.4. Исходные значения пакетов, обрабатываемых выходным конвейером

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

Таблица 4. Начальные значения для пакетов, обрабатываемых выходным конвейером.

NU

NM

CI2E

CE2E

packet_in

См. текст

user_meta

См. текст

Поля EgressParser istd (тип psa_egress_parser_input_metadata_t)

egress_port

Значение ostd.egress_port во входном пакете

Из конфигурации PRE для группы

Из конфигурации PRE для сеанса клонирования

packet_path

NORMAL_UNICAST

NORMAL_MULTICAST

CLONE_I2E

CLONE_E2E

Выходные поля istd (psa_egress_input_metadata_t)

class_of_service

Значение ostd.class_of_service во входном пакете

Из конфигурации PRE для сеанса клонирования

egress_port

То же значение, которое пол