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

То же значение, которое получено EgressParser (см. выше).

packet_path

То же значение, которое получено EgressParser (см. выше).

instance

0

Из конфигурации PRE для группы

Из конфигурации PRE для сеанса клонирования

egress_timestamp

Время начала обработки пакета в EgressParser. Заполняется независимо для каждой копии реплицированного пакета.

parser_error

От EgressParser. Всегда error.NoError, если при анализе не возникло ошибок.

6.4.1. Исходное содержимое обычных пакетов

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

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

6.4.2. Исходное содержимое клонов CI2E

Для пакетов CI2E значение packet_in берется из входного пакета, вызвавшего создание клона. Оно совпадает с содержимым packet_in входного пакета до IngressParser без изменений, внесенных входной обработкой. Поддерживается отсечка данных (payload) в пакетах.

Пакеты, клонированные во входном конвейере с сессией клонирования, где egress_port = PSA_PORT_RECIRCULATE, также относятся к этой категории.

6.4.3. Исходное содержимое клонов CE2E

Для пакетов CE2E значение packet_in берется из входного пакета, вызвавшего создание клона. Оно начинается с заголовков пакета, созданных выходным сборщиком, за которыми следует содержимое пакета, т. е. часть, не разбираемая выходным анализатором. Поддерживается отсечка данных (payload) в пакетах.

Пакеты, клонированные в выходном конвейере с сессией клонирования, где egress_port = PSA_PORT_RECIRCULATE, также относятся к этой категории.

6.4.4. Пользовательские метаданные для всех выходных пакетов

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

Основным отличием является использование для выходных пакетов иных путей. У выходного анализатора имеется 3 входных (in) параметра — normal_meta, clone_i2e_meta и clone_e2e_meta. Для каждого из пакетов в начале выходной обработки установлен один из этих параметров, а два оставшихся не определены.

Для пакетов NU и NM устанавливается лишь параметр normal_meta, принимая значение одноименного выходного (out) параметра входного сборщика при завершении входной обработки обычного пакета.

Для пакетов CLONE_I2E устанавливается лишь параметр clone_i2e_meta, принимая значение одноименного выходного (out) параметра входного сборщика при клонировании пакета.

Для пакетов CLONE_E2E устанавливается лишь параметр clone_e2e_meta, принимая значение одноименного выходного (out) параметра выходного сборщика при клонировании пакета.

6.4.5. Групповая адресация и клоны

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

  • egress_port — это поле обычно различается в разных копиях реплицированного пакета, но может совпадать у произвольного числа копий в соответствии с конфигурацией плоскости управления для PRE. Предполагается, что плоскость управления настраивает PRE так, чтобы у каждой копии исходного пакета была уникальная пара (egress_port, instance).
  • instance — см. egress_port.
  • egress_timestamp — это поле устанавливается независимо для каждой копии. В зависимости от объема трафика на каждом выходном порту значения могут существенно различаться у копий одного пакета.
  • parser_error — в общем случае значение этого поля будет совпадать у каждой копии одного реплицированного пакета. Однако в коде P4 для EgressParser поле определено независимо для каждой копии, поэтому при разном поведении, например, для разных egress_port значения parser_error также могут различаться.

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

6.5. Поведение пакетов по завершении выходной обработки

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

struct psa_egress_output_metadata_t {
	// В комментариях после полей указаны начальные значения по 
	// завершении работы блока управления Egress.
	bool			clone;			// false
	CloneSessionId_t	clone_session_id; 	// не определено
	bool			drop;			// false
}

psa_egress_input_metadata_t	istd;
psa_egress_output_metadata_t	ostd;

if (ostd.clone) {
	if (ostd.clone_session_id value is supported) {
		Из значений, настроенных для 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;	// Последующие операции не выполняются.
}
// Значение istd.egress_port ниже совпадает со значением в начале 
// выходной обработки в соответствии с решением предшествующей
// входной обработки пакета (или задано конфигурацией PRE для
// сеанса клонирования независимо от создания клона на входе или
// выходе). Выходному коду не разрешается изменять его.
if (istd.egress_port == PSA_PORT_RECIRCULATE) {
	Рециркулировать пакет, возвращая его во входной анализатор;
	return;	// Последующие операции не выполняются.
}
Размещение пакета в очереди для выходного порта istd.egress_port

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

6.6. Действия по направлению пакетов при выходной обработке

6.6.1. Отбрасывание пакета

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

/// Изменяются метаданные для отмены передачи пакета вовне.
/// Эта операция не влияет на поведение клонирования.
action egress_drop(inout psa_egress_output_metadata_t meta)
{
	meta.drop = true;
}

6.7. Содержимое передаваемого в порт пакета

С пакетами NTP и NTCPU не связывается метаданных.

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

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

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

P4 Runtime имеет свойство Packet In для приема пакетов, отправленных устройством PSA в порт PSA_PORT_CPU. С такими пакетами не связано метаданных и они включают лишь содержимое пакета, выдаваемое кодом EgressDeparser в программе P4. При этом могут выполняться некоторые преобразования полей заголовка, как описано в параграфе 4.1. Определения типов PSA.

6.8. Клонирование пакетов

Клонирование представляет собой механизм передачи пакетов в указанный порт в дополнение к передаче «обычного» пакета. Одна операция клонирования (clone) может создавать множество копий в зависимости от настройки плоскости управления.

Одним из применений клонирования является полное отображение трафика в другой порт (mirroring), т. е. обычная отправка пакетов адресату в соответствии с программой P4, сопровождаемая передачей копии пакета в другой порт, например, для системы мониторинга.

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

Логически PRE реализует механизмы копирования пакета. Клонированием управляют поля метаданных структур psa_ingress_output_metadata_t и psa_egress_output_metadata_t, имена которых начинаются с clone.

bool			clone;
CloneSessionId_t	clone_session_id;

Тег clone управляет клонированием пакета. При значении true клон пакета (пакетов) создается в конце конвейера. Поле clone_session_id указывает одну или несколько сессий клонирования, которые плоскость управления может настроить в PRE. Для каждой сессии клонирования плоскость управления может задать указанные ниже значения.

/// В каждой сессии клонирования могут создаваться пары (egress_port, instance).
PortId_t	egress_port; 	/// egress_port в паре (egress_port, instance).
EgressInstance_t instance; 	/// instance в паре (egress_port, instance).

/// Конфигурация сеанса клонирования задает в тоности 1 значение для указанных
/// ниже полей.
ClassOfService_t 	class_of_service;
bool			truncate;
PacketLength_t packet_length_bytes; /// Применяется только при truncate = true

Конфигурация набора пар (egress_port, instance) для сеанса клонирования похожа на конфигурацию пар для multicast-групп (6.2.1. Групповая репликация) в части требований и ограничений.

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

Для сокращения расхода пропускной способности может применяться отсечка при клонировании пакетов с передачей лишь заданного числа начальных байтов пакета. Это может быть полезно при отправке некоторых пакетов плоскости управления, а также системам сбора данных для мониторинга трафика. Если для сессии установлено значение truncate = false, выполняется клонирование пакетов целиком. В противном случае клон включает лишь первые packet_length_bytes байтов исходного пакета. Отсечка пакетов не оказывает влияния на сопровождающие пакет метаданные и размер метаданных не учитывается в packet_length_bytes. Отсечка выполняется для исходного пакета, переданного в параметре packet_in входному анализатору (для клонов со входа на выход), или передаваемого наружу как параметр packet_out из выходного сборщика (для клонов с выхода на выход). Реализации PSA могут поддерживать лишь ограниченный диапазон значений packet_length_bytes, например, кратные 32 байтам.

Поскольку в общем случае предполагается клонирование пакетов в CPU, каждая реализация PSA начинается с сеанса клонирования PSA_CLONE_SESSION_TO_CPU, инициализируемого парой (egress_port, instance) с egress_port = PSA_PORT_CPU и instance = 0. Для этой сессии также устанавливается class_of_service = 0 и truncate = false.

6.8.1. Примеры клонов

Ниже приведен фрагмент кода для клонирования пакетов.

header clone_i2e_metadata_t {
	bit<8> custom_tag;
	EthernetAddress srcAddr;
}
control ingress(inout headers hdr,
		 inout metadata user_meta,
		 in psa_ingress_input_metadata_t istd,
		 inout psa_ingress_output_metadata_t ostd)
{
	action do_clone (CloneSessionId_t session_id) {
		ostd.clone = true;
		ostd.clone_session_id = session_id;
		user_meta.custom_clone_id = 1;
	}
	table t {
		key = {
			user_meta.fwd_metadata.outport : exact;
		}
		actions = { do_clone; }
	}
	apply {
		t.apply();
	}
}
control IngressDeparserImpl(packet_out packet,
			      out clone_i2e_metadata_t clone_i2e_meta,
			      out empty_metadata_t resubmit_meta,
			      out metadata normal_meta,
			      inout headers hdr,
			      in metadata meta,
			      in psa_ingress_output_metadata_t istd)
{
	DeparserImpl() common_deparser;
	apply {
		// Назначение выходного параметра clone_i2e_meta должно выполняться
		// при выполнении приведенного ниже условия.
		if (psa_clone_i2e(istd)) {
			clone_i2e_meta.custom_tag = (bit<8>) meta.custom_clone_id;
			if (meta.custom_clone_id == 1) {
				clone_i2e_meta.srcAddr = hdr.ethernet.srcAddr;
			}
		}
		common_deparser.apply(packet, hdr);
	}
}

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

Повторное представление пакетов служит для повторения их обработки во входном конвейере и выполняется в конце этого конвейера. При повторном представлении пакета завершается его обработки во входном конвейере, после чего пакет снова представляется входному анализатору без выполнения сборки (deparse). Иными словами, повторно представленный пакет имеет тот же заголовок и данные, которые были у исходного пакета, сохраняется также значение ingress_port. Значение packet_path для повторно представленного пакета меняется на RESUBMIT.

Входной анализатор отличает повторно представленные пакеты от исходных по полю packet_path в метаданных ingress_parser_intrinsic_metadata_t. При анализе повторно представленного пакета может быть выбран другой алгоритм. Кроме того, входной конвейер может применить для такого пакета иное действие, нежели для исходного. Если платформа позволяет неоднократно выполнять повторное представление, пользовательская программа может различать такие пакеты по дополнительным метаданным, связанным с ними. Отметим, что максимальное симло повторов зависит от платформы (3. Пути пакетов).

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

Одним из применений повторного представления пакетов является повышение емкости и гибкости конвейера обработки пакетов. Например, неоднократная обработка пакета во входном конвейере позволяет увеличить число применяемых к пакету операций в N раз, где N — число повторов представления пакета.

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

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

Реализации PSA поддерживают конфигурационный флаг resubmit для PRE, включающий механизм повторного представления. При установленном флаге исходный пакет представляется снова вместе с необязательными метаданными, созданными при первом прохождении. Если флаг сброшен (false), механизм повторного представления отключается и метаданные resubmit_meta не устанавливаются.

6.10. Рециркуляция пакетов

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

Вопрос рециркуляции пакета решается во время входной обработки путем его отправки в специальный порт PSA_PORT_RECIRCULATE. Сама рециркуляция происходит в конце выходного конвейера. При отправке пакета в порт рециркуляции его выходная обработка завершается (включая выходной сборщик) и пакет возвращается входному анализатору. Поле ingress_port при рециркуляции пакета получает значение PSA_PORT_RECIRCULATE, а packet_path — RECIRCULATE.

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

7. Внешние блоки PSA

7.1. Ограничения на использование внешних блоков

Все экземпляры объектов в программе P416 создаются при компиляции и могут быть организованы в дерево, которое будем называть деревом реализации. Корень этого дерева (T) представляет верхний уровень программы, а его потомками являются пакет PSA_Switch, описанный в разделе 5. Программируемые блоки, и все внешние блоки, созданные на верхнем уровне программы. Потомками узла PSA_Switch являются пакеты и внешние блоки, переданные как параметры экземпляра PSA_Switch. На рисунке 3 показано минимально возможное дерево для программы P4, использующей архитектуру PSA.

 
Рисунок 3. Дерево минимального экземпляра PSA.

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

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

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

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

 

Тип внешнего блока

Блоки, могущие создавать и вызывать extern

ActionProfile

Ingress, Egress

ActionSelector

Ingress, Egress

Checksum

IngressParser, EgressParser, IngressDeparser, EgressDeparser

Counter

Ingress, Egress

Digest

IngressDeparser

DirectCounter

Ingress, Egress

DirectMeter

Ingress, Egress

Hash

Ingress, Egress

InternetChecksum

IngressParser, EgressParser, IngressDeparser, EgressDeparser

Meter

Ingress, Egress

Random

Ingress, Egress

Register

Ingress, Egress

 

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

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

Вызовы метода emit для типа packet_out могут в PSA размещаться лишь в блоках сборщиков, поскольку экзампляры packet_out видимы лишь в таких элементах управления. Точно также любые методы для типа packet_in (например, extract и advance) могут вызываться в программах PSA лишь из анализаторов. P416 ограничивает вызовы метода verify лишь синтаксическими анализаторами для всех программ P416, независимо от их предназначенности для PSA.

  • Предполагается, что высокопроизводительные реализации PSA не смогут обновлять один и тот же экземпляр extern из Ingress и Egress, а также из нескольких анализаторов или элементов управления, определенных в PSA.
  • В устройствах с несколькими конвейерами на деле имеется множество экземпляров входных и выходных конвейеров. Основной причиной создания множества конвейеров является практическая сложность доступа к одному объекту с поддержкой состояний (таблица, счетчик и т. п.) со скоростью, превышающей скорость пакетов в одном конвейере. Поэтому к объектам с поддержкой состояния следует обращаться лишь из одного конвейера в устройстве (см. Приложение E. Устройства PSA с несколькими конвейерами).

7.2. Свойства таблиц PSA

В таблице 6 указаны все свойства таблиц P4, определенные PSA, которые не включены в базовую спецификацию P416.

Таблица 6. Свойства таблиц PSA.

Свойство

Тип

Описание

psa_direct_counter

Имя одного экземпляра DirectCounter

7.7.3. Прямой счетчик

psa_direct_meter

Имя одного экземпляра DirectMeter

7.8. Измерители

psa_implementation

Имя одного экземпляра ActionProfile или ActionSelector

7.11. Профили действий, 7.12. Селекторы действий

psa_empty_group_action

action

7.12. Селекторы действий

psa_idle_timeout

PSA_IdleTimeout_t

7.2.1. Уведомление о тайм-ауте для записи таблицы

Реализации PSA недопустимо поддерживать оба свойства psa_implementation и psa_direct_counter в одной таблице. То же относится к одновременной поддержке свойств psa_implementation и psa_direct_meter.

7.2.1. Уведомление о тайм-ауте для записи таблицы

PSA использует свойство psa_idle_timeout для того, чтобы реализация таблицы могла передавать уведомления от устройства PSA по истечении заданного времени с момента последнего совпадения с записью таблицы. Это поле может принимать значение NO_TIMEOUT или NOTIFY_CONTROL. NO_TIMEOUT отключает уведомления и применяется по умолчанию, если свойство таблицы не задано. NOTIFY_CONTROL включает уведомления и реализация PSA будет генерировать API для плоскости управляния, позволяющий установить для записей таблицы срок действия (TTL), по истечении которого устройство будет передавать уведомление, если для записи не было найдено ни одного совпадения при поиске в таблице. Частота и режим генерации и доставки уведомлений плоскости управления определяются конфигурационными параметрами, задаваемыми API плоскости управления. Например,

enum PSA_IdleTimeout_t {
	NO_TIMEOUT,
	NOTIFY_CONTROL
}
table t {
	action a1 () { ... }
	action a2 () { ... }
	key = { hdr.f1: exact; }
	actions = { a1; a2; }
	default_action = a2;
	psa_idle_timeout = PSA_IdleTimeout_t.NOTIFY_CONTROL;
}

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

  • Вероятно любая аппаратная реализация будет иметь ограниченное число битов для представления значений и, поскольку значения задаются в процессе работы, модулю runtime (P4Runtime или иной программе контроллера) разумно гарантировать возможность представления значений TTL в устройстве. Это можно сделать путем задания зависимости от доступного на платформе числа битов, чтобы обеспечить представления диапазона значений в разных записях. Реализациям PSA следует разрешать программирование лишь соответствующих таблиц и выдавать сообщение об ошибке, если устройство совсем не поддерживает тайм-аут бездействия. Если тайм-аут не задан для записи таблицы, уведомления не будут передаваться даже при включенном свойстве.
  • PSA не требует тайм-аута для записи с принятым по умолчанию действием, поскольку принятое по умолчанию действие может не иметь в таблице явной записи, а также по причине отсутствия убедительных причин использования контроллером информации о долгом отсутствии соответствий с конкретной таблицей. Запись для принятого по умолчанию действия никогда не устаревает.
  • В настоящее время таблицы, реализованные с использованием ActionSelector и ActionProfile, не поддерживают свойство psa_idle_timeout. Это ограничение может быть исключено из будущих версий спецификации.

7.3. Блок репликации пакетов

Внешний блок PacketReplicationEngine (PRE) представляет часть конвейера PSA, которая не программируется кодом P4. Хотя PRE невозможно программировать с помощью P4, этот блок можно настраивать с использованием API плоскости управления (например, путем настройки multicast-гупп и сессий clone). Для каждого пакета программа P4 обычно будет устанавливать значения внутренних метаданных в таких структурах, как psa_ingress_output_metadata_t и psa_egress_output_metadata_t, которые управляют операциями PRE над пакетом. В файле psa.p4 определены некоторые действия, помогающие установить значения этих полей в наиболее распространенных ситуациях, описанных в параграфах 6.3. Действия по направлению пакетов при входной обработке и 6.6. Действия по направлению пакетов при выходной обработке.

экземпляр внешнего блока PRE должен создаваться однократно при создании экземпляра пакета PSA_Switch. Определения пакета из файла psa.p4 приведены в конце раздела 5. Программируемые блоки. Ниже приведен пример создания экземпляров, включая один экземпляр PacketReplicationEngine и один экземпляр BufferingQueueingEngine при создании экземпляра пакета PSA_Switch.

IngressPipeline(IngressParserImpl(),
		 ingress(),
		 IngressDeparserImpl()) ip;

EgressPipeline(EgressParserImpl(),
		egress(),
		EgressDeparserImpl())ep;

PSA_Switch(ip, PacketReplicationEngine(), ep, BufferingQueueingEngine()) main;

7.4. Блок буферизации пакетов

Внешний блок BufferingQueueingEngine (BQE) представляет другую часть конвейера PSA (после выходной обработки), которая не программируется кодом P4. Хотя BQE невозможно программировать с использованием P4, этот блок можно настраивать напрямую через API плоскости управления или путем установки внутренних метаданных.

Экземпляр внешнего блока должен создаваться однократно, как и PRE. Дополнительное обсуждение и пример кода представлены в параграфе 7.3. Блок репликации пакетов.

7.5. Хэш

Ниже перечислены поддерживаемые алгоритмы хэширования.

enum PSA_HashAlgorithm_t {
	IDENTITY,
	CRC32,
	CRC32_CUSTOM,
	CRC16,
	CRC16_CUSTOM,
	ONES_COMPLEMENT16,	/// 16-битовая контрольная сумма с дополнением до 1,
				/// применяемая в заголовках IPv4, TCP и UDP.
	TARGET_DEFAULT		/// Определяется реализацией платформы.
}

7.5.1. Хэш-функция

Пример использования приведен ниже.

parser P() {
	Hash<bit<16>>(PSA_HashAlgorithm_t.CRC16) h;
	bit<16> hash_value = h.get_hash(buffer);
}

Параметры хэш-функции представлены ниже.

  • algo — используемый для расчета алгоритм (7.5. Хэш).

  • O — тип возвращаемого функцией значения.

extern Hash<O> {
	/// Конструктор
	Hash(PSA_HashAlgorithm_t algo);
	/// Расчет хэш-значения для данных.
	/// @param data - данные для хэширования.
	/// @return - значение хэш-функции.
	O get_hash<D>(in D data);
	/// Расчет хэш-значения для data с модулем max и прибавлением base.
	/// @param base - минимальное возвращаемое значение.
	/// @param data - данные для хэширования.
	/// @param max - хэш-значение делится по модулю на max.
	/// Реализация может ограничивать максимальное поддерживаемое значение,
	/// например, величиной 32 или 256 а также может разрешать применение
	/// лишь степеней 2. Разработчикам P4 следует выбирать такие значения
	/// модуля, которые обеспечат требуемую переносимость.
	/// @return (base + (h % max)), где h - хэш-значение.
	O get_hash<T, D>(in T base, in D data, in T max);
}

7.6. Контрольные суммы

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

7.6.1. Базовая контрольная сумма

Базовый блок расчета контрольных сумм в PSA поддерживает произвольные алгоритмы хэширования и принимает 1 параметр:

  • W — размер контрольной суммы в битах.

extern Checksum<W> {
	/// Конструктор
	Checksum(PSA_HashAlgorithm_t hash);
	/// Сброс внутреннего состояния и подготовка блока к расчетам. Каждый
	/// экземпляр объекта Checksum инициализируется автоматически, как будто
	/// для него вызвана функция clear(). Инициализация выполняется при 
	/// создании каждого экземпляра, т. е. при каждом применении анализатора
	/// или элемента управления с объектом Checksum. Все состояния 
	/// поддерживаются объектом Checksum независимо для каждого пакета.
	void clear();
	/// Добавление данных в контрольную сумму.
	void update<T>(in T data);
	/// Получение контрольной суммы после добавления (но без удаления) данных
	/// с последнего вызова clear.
	W	get();
}

7.6.2. Инкрементная контрольная сумма

PSA поддерживает также инкрементальный расчет контрольных сумм, включающий дополнительный метод исключения данных, учтенных в предшествующем расчете. Контрольные суммы рассчитываются по алгоритму хеширования ONES_COMPLEMENT16, используемому протоколами IPv4, TCP и UDP (см. IETF RFC 1624 и Приложение B. Реализация внешнего блока InternetChecksum).

// Контрольные суммы на основе алгоритма ONES_COMPLEMENT16 применяются в IPv4, 
// TCP и UDP. Поддерживается инкрементное обновление с помощью метода subtract.
// См. IETF RFC 1624.
extern InternetChecksum {
	/// Конструктор
	InternetChecksum();
	/// Сброс внутреннего состояния и подготовка блока к расчетам. Каждый
	/// экземпляр объекта InternetChecksum инициализируется автоматически, 
	/// как будто для него вызвана функция clear(). Инициализация происходит 
	/// при создании каждого экземпляра, т. е. при каждом применении анализатора
	/// или элемента управления с этим объектом. Все состояния 
	/// поддерживаются объектом Checksum независимо для каждого пакета.
	void clear();
	/// Добавление данных в контрольную сумму. Размер data должен быть кратным 16.
	void add<T>(in T data);
	/// Исключение data из имеющейся контрольной суммы. Размер data должен быть
	/// кратным 16.
	void subtract<T>(in T data);
	/// Получение контрольной суммы после добавления (но без удаления) данных
	/// с последнего вызова clear.
	bit<16> get();
	/// Получение текущего статуса расчета контрольной суммы. Возвращаемое 
	/// значение предназначено лишь для будущих вызовоа метода set_state.
	bit<16> get_state();
	/// Восстанавливает состояние экземпляра InternetChecksum к одному из ранее
	/// возвращенных методом get_state. Это состояние может относиться к тому же
	/// или иному экземпляру внешнего блока InternetChecksum.
	void set_state(in bit<16> checksum_state);
}

7.6.3. Примеры InternetChecksum

Приведенный ниже фрагмент программы показывает использование внешнего блока InternetChecksum для проверки поля контрольной суммы в разобранном заголовке IPv4 и возврата ошибки анализатора при некорректном значении. Показаны также ошибки анализатора в блоке управления Ingress и отбрасывание пакетов в случае ошибки. Программы PSA могут обрабатывать пакеты с ошибками иначе, чем показано в примере и этот отдано на откуп разработчикам программ P4.

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

// Определение дополнительных кодов ошибок для пакетов с некорректной 
// контрольной суммой заголовка IPv4.
error {
	UnhandledIPv4Options,
	BadIPv4HeaderChecksum
}
typedef bit<32> PacketCounter_t;
typedef bit<8> ErrorIndex_t;
const bit<9> NUM_ERRORS = 256;
parser IngressParserImpl(packet_in buffer,
			   out headers hdr,
			   inout metadata user_meta,
			   in psa_ingress_parser_input_metadata_t istd,
			   in empty_metadata_t resubmit_meta,
			   in empty_metadata_t recirculate_meta)
{
	InternetChecksum() ck;
	state start {
		buffer.extract(hdr.ethernet);
		transition select(hdr.ethernet.etherType) {
			0x0800: parse_ipv4;
			default: accept;
		}
	}
	state parse_ipv4 {
		buffer.extract(hdr.ipv4);
		// TBD: Было бы хорошо расширить этот пример для демонстрации
		// проверки контрольной суммы в заголовках IPv4 с опциями, но 
		// в данном примере не обрабатываются такие пакеты.
		verify(hdr.ipv4.ihl == 5, error.UnhandledIPv4Options);
		ck.clear();
		ck.add({
			/* 16-битовое слово 0	*/ hdr.ipv4.version, hdr.ipv4.ihl, hdr.ipv4.diffserv,
			/* 16-битовое слово 1	*/ hdr.ipv4.totalLen,
			/* 16-битовое слово 2	*/ hdr.ipv4.identification,
			/* 16-битовое слово 3	*/ hdr.ipv4.flags, hdr.ipv4.fragOffset,
			/* 16-битовое слово 4	*/ hdr.ipv4.ttl, hdr.ipv4.protocol,
			/* 16-битовое слово 5 skip hdr.ipv4.hdrChecksum, */
			/* 16-битовые слова 6-7 	*/ hdr.ipv4.srcAddr,
			/* 16-битовые слова 8-9 	*/ hdr.ipv4.dstAddr
			});
		// Оператор verify, приведенный ниже, будет переводить анализатор
		// в состояние reject, незамедлительно прерывая разбор при ошибке
		// в контрольной сумме заголовка IPv4. При этом записывается ошибка
		// error.BadIPv4HeaderChecksum, что будет доступно в поле метаданных
		// входного блока управления.
		verify(ck.get() == hdr.ipv4.hdrChecksum,
			error.BadIPv4HeaderChecksum);
		transition select(hdr.ipv4.protocol) {
			6: parse_tcp;
			default: accept;
		}
	}
	state parse_tcp {
		buffer.extract(hdr.tcp);
		transition accept;
	}
}
control ingress(inout headers hdr,
		 inout metadata user_meta,
		 in psa_ingress_input_metadata_t istd,
		 inout psa_ingress_output_metadata_t ostd)
{
	// Таблица parser_error_count_and_convert, приведенная ниже, показывает
	// один из способов учета числа разных ошибок анализа. Хотя в примере
	// это не используется, показано также преобразование кода ошибки в 
	// уникальное значение вектора битов error_idx, который может быть 
	// полезен для кодирования ошибок в заголовке пакета (например, при 
	// отправке CPU).
	DirectCounter<PacketCounter_t>(PSA_CounterType_t.PACKETS) parser_error_counts;
	ErrorIndex_t error_idx;
	action set_error_idx (ErrorIndex_t idx) {
		error_idx = idx;
		parser_error_counts.count();
	}
	table parser_error_count_and_convert {
		key = {
			istd.parser_error : exact;
		}
		actions = {
			set_error_idx;
		}
		default_action = set_error_idx(0);
		const entries = {
			error.NoError			: set_error_idx(1);
			error.PacketTooShort		: set_error_idx(2);
			error.NoMatch			: set_error_idx(3);
			error.StackOutOfBounds		: set_error_idx(4);
			error.HeaderTooShort		: set_error_idx(5);
			error.ParserTimeout		: set_error_idx(6);
			error.BadIPv4HeaderChecksum 	: set_error_idx(7);
			error.UnhandledIPv4Options 	: set_error_idx(8);
		}
		psa_direct_counter = parser_error_counts;
	}
	apply {
		if (istd.parser_error != error.NoError) {
			// Пример кода, учитывающего каждый тип ошибок анализатора.
			parser_error_count_and_convert.apply();
			ingress_drop(ostd);
			exit;
		}
		// Здесь выполняется обычная обработка пакета.
	}
}

Ниже приведен фрагмент программы, показывающий использование внешнего блока InternetChecksum для расчета и заполнения поля контрольной суммы IPv4 в блоке сборщика. В этом примере контрольная сумма обновляется и результат будет корректным независимо от изменений полей заголовка IPv4 в предшествующем блоке управления Ingress (или Egress).

control EgressDeparserImpl(packet_out packet,
			     out empty_metadata_t clone_e2e_meta,
			     out empty_metadata_t recirculate_meta,
			     inout headers hdr,
			     in metadata meta,
			     in psa_egress_output_metadata_t istd,
			     in psa_egress_deparser_input_metadata_t edstd)
{
	InternetChecksum() ck;
	apply {
		ck.clear();
		ck.add({
			/* 16-битовое слово 0	*/ hdr.ipv4.version, hdr.ipv4.ihl, hdr.ipv4.diffserv,
			/* 16-битовое слово 1	*/ hdr.ipv4.totalLen,
			/* 16-битовое слово 2	*/ hdr.ipv4.identification,
			/* 16-битовое слово 3	*/ hdr.ipv4.flags, hdr.ipv4.fragOffset,
			/* 16-битовое слово 4	*/ hdr.ipv4.ttl, hdr.ipv4.protocol,
			/* 16-битовое слово 5 пропуск hdr.ipv4.hdrChecksum, */
			/* 16-битовые слова 6-7 	*/ hdr.ipv4.srcAddr,
			/* 16-битовые слова 8-9 	*/ hdr.ipv4.dstAddr
			});
		hdr.ipv4.hdrChecksum = ck.get();
		packet.emit(hdr.ethernet);
		packet.emit(hdr.ipv4);
		packet.emit(hdr.tcp);
	}
}

В качестве финального примера показано использование InternetChecksum для инкрементного расчета контрольной суммы TCP. Напомним, что контрольная сумма TCP рассчитывается для всего пакета, включая заголовок. Поскольку тело пакета не доступно реализации PSA, предполагается, что контрольная сумма TCP для исходного пакета корректна и значение обновляется инкрементально вызовом методов subtract и add для всех полей, измененных программой. Например, блок управления Ingress в приведенной ниже программе меняет адрес отправителя IPv4, записывая исходный адрес в поле метаданных.

control ingress(inout headers hdr,
		 inout metadata user_meta,
		 in psa_ingress_input_metadata_t istd,
		 inout psa_ingress_output_metadata_t ostd) {
	action drop() {
		ingress_drop(ostd);
	}
	action forward(PortId_t port, bit<32> srcAddr) {
		user_meta.fwd_metadata.old_srcAddr = hdr.ipv4.srcAddr;
		hdr.ipv4.srcAddr = srcAddr;
		send_to_port(ostd, port);
	}
	table route {
		key = { hdr.ipv4.dstAddr : lpm; }
		actions = {
			forward;
			drop;
		}
	}
	apply {
		if(hdr.ipv4.isValid()) {
			route.apply();
		}
	}
}

Сборщик сначала обновляет контрольную суммы IPv4, как показано выше, затем инкрементально рассчитывает контрольную сумму TCP.

control EgressDeparserImpl(packet_out packet,
			     out empty_metadata_t clone_e2e_meta,
			     out empty_metadata_t recirculate_meta,
			     inout headers hdr,
			     in metadata user_meta,
			     in psa_egress_output_metadata_t istd,
			     in psa_egress_deparser_input_metadata_t edstd)
{
	InternetChecksum() ck;
	apply {
		// Обновление контрольной суммы IPv4. Этот вызов clear() 
		// можно удалить, поскольку экземпляр InternetCheckum 
		// автоматически сбрасывается для каждого пакета.
		ck.clear();
		ck.add({
			/* 16-битовое слово 0	*/ hdr.ipv4.version, hdr.ipv4.ihl, hdr.ipv4.diffserv,
			/* 16-битовое слово 1	*/ hdr.ipv4.totalLen,
			/* 16-битовое слово 2	*/ hdr.ipv4.identification,
			/* 16-битовое слово 3	*/ hdr.ipv4.flags, hdr.ipv4.fragOffset,
			/* 16-битовое слово 4	*/ hdr.ipv4.ttl, hdr.ipv4.protocol,
			/* 16-битовое слово 5 пропуск hdr.ipv4.hdrChecksum, */
			/* 16-битовые слова 6-7 	*/ hdr.ipv4.srcAddr,
			/* 16-битовые слова 8-9 	*/ hdr.ipv4.dstAddr
			});
		hdr.ipv4.hdrChecksum = ck.get();
		// Обновление контрольной суммы TCP. Этот вызов clear() нужен, 
		// поскольку повторно используется тот же экземпляр ck для 
		// того же пакета. Если применить взамен другой экземпляр 
		// InternetChecksum вместо ck, вызов clear() не нужен.
		ck.clear();
		// Вычитание исходной контрольной суммы TCP
		ck.subtract(hdr.tcp.checksum);
		// Учет удаления исходного адреса отправителя IPv4, являющегося
		// частью псевдозаголовка TCP для расчета контрольной суммы 
		// TCP (см. RFC 793), затем учет влияния нового адреса отправителя
		// отправителя IPv4.
		ck.subtract(user_meta.fwd_metadata.old_srcAddr);
		ck.add(hdr.ipv4.srcAddr);
		hdr.tcp.checksum = ck.get();
		packet.emit(hdr.ethernet);
		packet.emit(hdr.ipv4);
		packet.emit(hdr.tcp);
	}
}

7.7. Счетчики

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

Прямыми (direct counter) называют счетчики, связанные с конкретной таблицей P4 и реализованные с помощью внешнего блока DirectCounter. Кроме того, имеются индексированные счетчики, которые реализуются с помощью внешнего блока Counter. Основные различия между прямыми и индексированными счетчиками указаны ниже.

  • Число независимо обновляемых значений счетчиков:
    • один экземпляр прямого счетчика всегда содержит столько независимых значений, сколько записей имеется в таблице, связанной с этим счетчиком;
    • для индексированного счетчика число независимых значений можно задать при создании экземпляра и эти числа могут отличаться от числа записей в таблицах.
  • Обновление значений счетчиков в программе P4:
    • для прямых счетчиков вызов метода count доступен лишь из действий в таблице, с которой связан счетчик, поэтому значения счетчиков обновляются при совпадении с соответствующей записью таблицы;
    • для индексированных счетчиков метод count можно вызывать из любого места программы P4, где разрешены вызовы внешних объектов (например, в действии или напрямую в блоке apply элемента управления) и при каждом вызове метода должен указываться индекс обновляемого значения.

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

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

7.7.1. Типы счетчиков

enum PSA_CounterType_t {
	PACKETS,
	BYTES,
	PACKETS_AND_BYTES
}

7.7.2. Непрямой счетчик

/// Непрямой счетчик с n_counters независимых значений, где каждое
/// значение имеет в плоскости данных размер, заданный типом W.
extern Counter<W, S> {
	Counter(bit<32> n_counters, PSA_CounterType_t type);
	void count(in S index);
	/*
	/// API плоскости управления использует 64-битовые значения счетчиков. 
	/// Это не отражает размеры счетчиков в плоскости данных.
	/// Предполагается, что программы плоскости управления периодически
	/// считывают значения счетчиков плоскости данных и собирают их в
	/// более крупных счетчиках, которые позволяют учет в течение 
	/// продолжительного времени без переполнения. 64-битовые счетчики
	/// при скорости интерфейсов 100 Гбит/с будут переполняться 
	/// примерно через 46 лет.
	@ControlPlaneAPI
	{
		bit<64> read		(in S index);
		bit<64> sync_read	(in S index);
		void set		(in S index, in bit<64> seed);
		void reset		(in S index);
		void start		(in S index);
		void stop		(in S index);
	}
	*/
}

Псевдокод внешнего блока Counter приведен в Приложении C. Пример реализации внешнего блока Counter.

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

7.7.3. Прямой счетчик

extern DirectCounter<W> {
	DirectCounter(PSA_CounterType_t type);
	void count();
	/*
	@ControlPlaneAPI
	{
		W	read<W>		(in TableEntry key);
		W	sync_read<W>	(in TableEntry key);
		void 	set		(in TableEntry key, in W seed);
		void 	reset		(in TableEntry key);
		void 	start		(in TableEntry key);
		void 	stop		(in TableEntry key);
	}
	*/
}

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

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

Реализация внешнего блока DirectCounter практически совпадает с реализацией Counter. Отсутствие индекса как параметра метода count позволяет исключить проверку корректности значения индекса.

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

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

7.7.4. Пример использования счетчиков

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

typedef bit<48> ByteCounter_t;
typedef bit<32> PacketCounter_t;
typedef bit<80> PacketByteCounter_t;
const bit<32> NUM_PORTS = 512;
struct headers {
	ethernet_t	ethernet;
	ipv4_t		ipv4;
}
control ingress(inout headers hdr,
		 inout metadata user_meta,
		 in psa_ingress_input_metadata_t istd,
		 inout psa_ingress_output_metadata_t ostd)
{
	Counter<ByteCounter_t, PortId_t>(NUM_PORTS, PSA_CounterType_t.BYTES)
		port_bytes_in;
	DirectCounter<PacketByteCounter_t>(PSA_CounterType_t.PACKETS_AND_BYTES)
		per_prefix_pkt_byte_count;
	action next_hop(PortId_t oport) {
		per_prefix_pkt_byte_count.count();
		send_to_port(ostd, oport);
	}
	action default_route_drop() {
		per_prefix_pkt_byte_count.count();
		ingress_drop(ostd);
	}
	table ipv4_da_lpm {
		key = { hdr.ipv4.dstAddr: lpm; }
		actions = {
			next_hop;
			default_route_drop;
		}
	default_action = default_route_drop;
	// Таблица ipv4_da_lpm владеет этим экземпляром DirectCounter.
	psa_direct_counter = per_prefix_pkt_byte_count;
} apply {
	port_bytes_in.count(istd.ingress_port);
	if (hdr.ipv4.isValid()) {
	ipv4_da_lpm.apply();
}
control egress(inout headers hdr,
		inout metadata user_meta,
		in psa_egress_input_metadata_t istd,
		inout psa_egress_output_metadata_t ostd)
{
	Counter<ByteCounter_t, PortId_t>(NUM_PORTS, PSA_CounterType_t.BYTES)
		port_bytes_out;
	apply {
		// Это обновление выполняется на выходе, поскольку групповая
		// репликация выполняется до выходной обработки. В результате
		// обновление будет выполняться для каждой копии.
		port_bytes_out.count(istd.egress_port);
	}
}

7.8. Измерители

Измерители (RFC 2698) обеспечивают более сложные механизмы сбора статистики по сравнению со счетчиками. Их чаще всего применяют для маркировки или отбрасывания пакетов, для которых скорость (в пакетах или битах) превышает среднее значение. Маркировка пакета означает изменение одного или нескольких параметров качества обслуживания в заголовках пакетов, таких как 802.1Q PCP14 или биты DSCP15 в байте типа обслуживания IPv4 или IPv6. Заданные в PSA измерители являются «трехцветными».

От измерителей PSA не требуется выполнение действий по отбрасыванию или маркировке и они не выполняют таких действий автоматически. Измерители сохраняют и обновляют состояние при вызове метода execute(), возвращая значение GREEN (соответствие), YELLOW (избыток) или RED (нарушение). Условия возврата того или иного значения описаны в RFC 2698. Программа P4 отвечает за проверку возвращаемых значений и изменение поведения пакетов в соответствии с результатом. При инициализации измерителей устанавливается значение GREEN (спецификация P4).

В RFC 2698 рассмотрены осведомленные (color aware) и «слепые» (color blind) варианты измерителей. Внешние блоки Meter и DirectMeter реализуют оба варианта. Единственным различием является метод обновления, как отмечено в комментариях к приведенному ниже коду.

Подобно счетчикам, измерители делятся на прямые и индексированные. Непрямые измерители указываются индексом, а прямые связаны с записями таблиц и обновляются при совпадении записи с ключом поиска. Из API плоскости управления доступ к прямым измерителям выполняет P4 Runtime по записи таблицы в качестве ключа.

Между счетчиками и измерителями имеется много общего, как показано ниже.

  • Число независимых обновляемых значения.
  • Точки возможного обновления значений из программы P4.
  • Для измерителей типа BYTES при обновлении используется размер пакета в соответствии с реализацией PSA (подход реализаций может различаться).

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

  • Метод execute для DirectMeter должен вызываться из действия, вызванного таблицей, которая владеет экземпляром DirectMeter. Действия не обязаны вызывать метод execute, но могут делать это.
  • Должно быть состояние измерителя для экземпляра DirectMeter, обновляемое при отсутствии совпадений (miss) в таблице-владельце. Как и для DirectCounter, это состояние требуется лишь в таблицах, включающих принятое по умолчанию действие.

Атрибутом таблицы, указывающим, что она владеет экземпляром DirectMeter, является psa_direct_meter. Значением этого атрибута таблицы является имя экземпляра DirectMeter.

Если для измерителя вызывается execute(idx) со значением idx, выходящим за пределы диапазона индексов, состояние измерителя не меняется (как и для счетчиков). Вызов execute возвращает значение PSA_MeterColor_t, но оно не определено. Программе, желающие обеспечить предсказуемое поведение должны предотвращать влияние таких значений на выходные пакеты и возникновение иных побочных эффектов. В приведенном ниже примере кода показан один из способов обеспечить предсказуемое поведение. Отметим, что неопределенностей в поведении не возникает, если значение n_meters для индексированного измерителя равно 2W, а использованный для создания измерителя тип S представляет собой bit<W> (в таких случаях индекс просто не выходит за границы диапазона).

#define METER1_SIZE 100
Meter<bit<7>>(METER1_SIZE, PSA_MeterType_t.BYTES) meter1;
bit<7> idx;
PSA_MeterColor_t color1;
// ... later ...
if (idx < METER1_SIZE) {
	color1 = meter1.execute(idx, PSA_MeterColor_t.GREEN);
} else {
	// Если idx выходит за границы диапазона, используется принятое
	// по умолчанию значение для color1. Можно также сохранять флаг
	// ошибки в поле метаданных.
	color1 = PSA_MeterColor_t.RED;
}

Для любой реализации диапазон значений Peak Burst Size и Committed Burst Size является конечным и в документации следует указывать поддерживаемые размеры пиков. Если реализация выполняет внутреннюю отсечку запрашиваемых плоскостью управления значений, это также следует указать в документации. В качестве максимального размера пиков рекомендуется устанавливать значение не меньше числа байтов, передаваемых с максимальной скоростью порта в течение 100 мсек.

Реализации могут также ограничивать диапазон и точность значений Peak Information Rate и Committed Information Rate. В документации следует указывать максимальное поддерживаемое значение, а также точность задания значений. Рекомендуется ограничивать максимально поддерживаемую скорость значением не меньше скорости наиболее быстрого порта, а фактическую скорость устанавливать с отклонением в пределах 0,1% от запрошенной.

7.8.1. Типы измерителей

enum PSA_MeterType_t {
	PACKETS,
	BYTES
}

7.8.2. Цвета для измерителей

enum PSA_MeterColor_t { RED, GREEN, YELLOW }

7.8.3. Непрямой измеритель

// Индексированный измеритель с n_meters независимых значений.
extern Meter<S> {
	Meter(bit<32> n_meters, PSA_MeterType_t type);
	// Этот метод вызывается для осведомленных о цветах измерителей 
	// (см. RFC 2698). Цвет пакета перед вызовом метода указывается
	// параметром color.
	PSA_MeterColor_t execute(in S index, in PSA_MeterColor_t color);
	// Этот метод вызывается для обновления «слепого» измерителя
	// (см. RFC 2698). Его можно реализовать вызовом execute(index,
	// MeterColor_t.GREEN), обеспечивающим такое же поведение.
	PSA_MeterColor_t execute(in S index);
	/*
	@ControlPlaneAPI
	{
		reset(in MeterColor_t color);
		setParams(in S index, in MeterConfig config);
		getParams(in S index, out MeterConfig config);
	}
	*/
}

7.8.4. Прямой измеритель

extern DirectMeter {
	DirectMeter(PSA_MeterType_t type);
	// См. описание методов для Meter.
	PSA_MeterColor_t execute(in PSA_MeterColor_t color);
	PSA_MeterColor_t execute();
	/*
	@ControlPlaneAPI
	{
		reset(in TableEntry entry, in MeterColor_t color);
		void setConfig(in TableEntry entry, in MeterConfig config);
		void getConfig(in TableEntry entry, out MeterConfig config);
	}
	*/
}

7.9. Регистры

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

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

Для экземпляров Register имеется два разных конструктора. Значения, возвращаемое для неициализированного варианта, будет неопределенным, а для инициализированного — заданным параметром конструктора initial_value.

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

extern Register<T, S> {
	/// Создание массива из <size> регистров. Начальные значения не 
	/// определены.
	Register(bit<32> size);
	/// Инициализация массива из <size> регистров с установкой 
	/// начального значения initial_value.
	Register(bit<32> size, T initial_value);
	T	read 	(in S index);
	void 	write 	(in S index, in T value);
	/*
	@ControlPlaneAPI
	{
		T	read<T>	(in S index);
		void 	set	(in S index, in T seed);
		void 	reset	(in S index);
	}
	*/
}

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

const bit<32> NUM_PORTS = 512;
// Более удобно применять для представления комбинированного счетчика 
// пакетов и байтов, а также других комбинированных значений тип struct 
// и хранить значения в экземпляре Register. Однако версия p4test от
// 10.02.2018 не позволяет возвращать тип struct из вызовов, подобных
// Register.read(). Этот вопрос обсуждается на Github (см. 
// https://github.com/p4lang/p4-spec/issues/383) 
#define PACKET_COUNT_WIDTH 32
#define BYTE_COUNT_WIDTH 48
//#define PACKET_BYTE_COUNT_WIDTH (PACKET_COUNT_WIDTH + BYTE_COUNT_WIDTH)
#define PACKET_BYTE_COUNT_WIDTH 80
#define PACKET_COUNT_RANGE (PACKET_BYTE_COUNT_WIDTH-1):BYTE_COUNT_WIDTH
#define BYTE_COUNT_RANGE (BYTE_COUNT_WIDTH-1):0
typedef bit<PACKET_BYTE_COUNT_WIDTH> PacketByteCountState_t;
action update_pkt_ip_byte_count (inout PacketByteCountState_t s,
				   in bit<16> ip_length_bytes)
{
	s[PACKET_COUNT_RANGE] = s[PACKET_COUNT_RANGE] + 1;
	s[BYTE_COUNT_RANGE] = (s[BYTE_COUNT_RANGE] +
		(bit<BYTE_COUNT_WIDTH>) ip_length_bytes);
}
control ingress(inout headers hdr,
		 inout metadata user_meta,
		 in psa_ingress_input_metadata_t istd,
		 inout psa_ingress_output_metadata_t ostd)
{
	Register<PacketByteCountState_t, PortId_t>(NUM_PORTS)
		port_pkt_ip_bytes_in;
	apply {
		ostd.egress_port = (PortId_t) 0;
		if (hdr.ipv4.isValid()) {
			@atomic {
				PacketByteCountState_t tmp;
				tmp = port_pkt_ip_bytes_in.read(istd.ingress_port);
				update_pkt_ip_byte_count(tmp, hdr.ipv4.totalLen);
				port_pkt_ip_bytes_in.write(istd.ingress_port, tmp);
			}
		}
	}
}

Отметим использование аннотации @atomic в блоке, включающем вызовы методов read() и write() экземпляра Register. Считается, что в общем случае при доступе к регистрам нужна аннотация @atomic для блока кода, чтобы обеспечить нужное поведение. Как указано в спецификации P416, без аннотации @atomic в этом примере реализация может параллельно обрабатывать два пакета P1 и P2 с доступом к регистрам в показанном ниже порядке.

	// Возможный порядок операций для программы без аннотации @atomic.
	tmp = port_pkt_ip_bytes_in.read(istd.ingress_port);	// Для пакета P1
	tmp = port_pkt_ip_bytes_in.read(istd.ingress_port);	// Для пакета P2
	// Здесь пакеты P1 и P2 приходят из одного ingress_port и значения
	// tmp для них совпадают.
	update_pkt_ip_byte_count(tmp, hdr.ipv4.totalLen);	// Для пакета P1
	update_pkt_ip_byte_count(tmp, hdr.ipv4.totalLen);	// Для пакета P2
	port_pkt_ip_bytes_in.write(istd.ingress_port, tmp);	// Для пакета P1
	port_pkt_ip_bytes_in.write(istd.ingress_port, tmp);	// Для пакета P2
	// Операция write() для пакета P1 будет потеряна.

Поскольку реализации по разному могут ограничивать сложность кода, воспринимаемого в блоке @atomic, рекомендуется делать его по-возможности коротким.

Вызовы отдельных методов для счетчиков и измерителей не нужно включать в блоки @atomic, поскольку для них гарантирована неделимость без потери внесенных изменений. Хотя спецификация P416 v1.0.0 требует от каждого действия (action) в таблице неделимого поведения, как при использовании аннотации @atomic для всего действия, рекомендуется явно использовать аннотации @atomic внутри тела действий, поскольку (a) это безопасно и (b), что более важно, упомянутое требование может быть исключено в будущих версиях спецификации.

Как и для индексированных измерителей и счетчиков, доступ к индексируемым регистрам должен выполняться с соблюдением границ значений индекса. Запись в регистр с выходящим за границу индексом не будет давать результата, а чтение вернет неопределенное значение. В примере параграфа 7.8. Измерители показан код, гарантирующий предотвращение упомянутых неопределенностей. Выход за границы индекса регистра становится невозможным, если экземпляр регистра объявлен с типом S как bit<W> и размером 2W.

7.10. Случайные числа

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

extern Random<T> {
	/// Возвращает случайное значение из диапазона [min, max]. Реализациям
	/// разрешено поддерживать диапазоны, где значение (max - min + 1)
	/// является степенью 2. Разработчикам P4 следует ограничивать значения
	/// аргументов соответствующими числами для переносимости программ.
	Random(T min, T max);
	T read();
	/*
	@ControlPlaneAPI
	{
		void reset();
		void setSeed(in T seed);
	}
	*/
}

7.11. Профили действий

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

 
Рисунок 4. Профили действий в PSA.

На рисунке 4 сравниваются прямые (direct) таблицы и таблицы с реализацией профиля действий. Прямая таблица, как показано на рисунке 4 (a), содержит спецификацию действия в каждой своей записи. На рисунке показан пример таблицы LPM с полем заголовка h.f в качестве ключа поиска. Действием служит указание порта. Видно, что записи t1 и t3 имеют одно действие, т. е. устанавливают порт 1. Профили действий позволяют совместно использовать действие в записях разных таблиц, как показано на рисунке 4(b). Таблица с реализацией профиля действий имеет записи, указывающие элемент профиля вместо спецификации конкретного действия. Сопоставление элементов профиля со спецификациями действий поддерживается в отдельной таблице, которая является частью заданного профиля действий. При использовании таблицы с реализацией профиля действий ссылка на элемент профиля преобразуется в спецификацию конкретных действий, применяемых к пакету.

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

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

extern ActionProfile {
	/// Создание профиля действий с числом элементов size.
	ActionProfile(bit<32> size);
	/*
	@ControlPlaneAPI
	{
		entry_handle 	add_member	(action_ref, action_data);
		void		delete_member 	(entry_handle);
		entry_handle 	modify_member 	(entry_handle, action_ref, action_data);
	}
	*/
}

7.11.1. Пример профиля действий

Блок управления P4 Ctrl в приведенном ниже примере создает экземпляр профиля действий ap, который может включать до 128 элементов. Таблица indirect применяет этот экземпляр путем установки атрибута psa_implementation. Плоскость управления может добавлять элементы в ap и каждый элемент может задавать действие foo или NoAction. Записи таблицы indirect должны указывать действия, используя заданные контроллером ссылки на элементы профиля.

control Ctrl(inout H hdr, inout M meta) {
	action foo() { meta.foo = 1; }
	ActionProfile(128) ap;
	table indirect {
		key = {hdr.ipv4.dst_address: exact;}
		actions = { foo; NoAction; }
		psa_implementation = ap;
	}
	apply {
		indirect.apply();
	}
}

7.12. Селекторы действий

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

 
Рисунок 5. Селекторы действий в PSA.

На рисунке 5 показана таблица с реализацией селектора действий, использующая сопоставление LPM для поля h.f. Второй селектор типа сопоставления служит для задания полей, используемых при поиске спецификации действия в процессе работы.

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

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

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

Ниже приведены минимальные требования к селекторам действий в реализации PSA.

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

Дополнительные расширения:

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

Свойство таблицы psa_empty_group_action походе на свойство default_action:

  • оба используют действие в качестве значения;

  • начальное значение задает код P4;

  • при отсутствии свойства psa_empty_group_action в коде P4 используется NoAction();

  • может применяться модификатор const, запрещающий управляющей программе изменять действие;
  • при отсутствии модификатора const управляющая программа может менять действие psa_empty_group_action.

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

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

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

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

extern ActionSelector {
	/// Создание селектора действий с size записей.
	/// @param algo - алгоритм хеширования для выбора члена группы.
	/// @param size - число записей в селекторе действий.
	/// @param outputWidth - размер ключа.
	ActionSelector(PSA_HashAlgorithm_t algo, bit<32> size, bit<32> outputWidth);
	/*
	@ControlPlaneAPI
	{
		entry_handle	add_member		(action_ref, action_data);
		void		delete_member		(entry_handle);
		entry_handle 	modify_member		(entry_handle, action_ref, action_data);
		group_handle 	create_group		();
		void		delete_group		(group_handle);
		void		add_to_group		(group_handle, entry_handle);
		void		delete_from_group	(group_handle, entry_handle);
	}
	*/
}

7.12.1. Пример селектора действий

Блок управления P4 Ctrl в приведенном ниже примере создает экземпляр селектора действий as, который может включать до 128 элементов. Селектор применяет алгоритм crc16 с 10-битовым результатом для выбора элементов в группе.

Таблица indirect_with_selection применяет этот экземпляр путем установки атрибута psa_implementation. Плоскость управления может добавлять элементы и группы в as и каждый элемент может задавать действие foo или NoAction. При программировании записей таблицы плоскость управления не включает поля селектора типа сопоставления в ключ сопоставления. Вместо этого поля селектора типа сопоставления используются для создания списка, передаваемого экземпляру селектора действий. В приведенном ниже примере список {hdr.ipv4.src_address, hdr.ipv4.protocol} передается на вход алгоритма хэширования crc16, используемого для динамического выбора в селекторе действий as.

control Ctrl(inout H hdr, inout M meta) {
	action foo() { meta.foo = 1; }
	ActionSelector(PSA_HashAlgorithm_t.CRC16, 128, 10) as;
	table indirect_with_selection {
		key = {
			hdr.ipv4.dst_address: exact;
			hdr.ipv4.src_address: selector;
			hdr.ipv4.protocol: selector;
		}
	actions = { foo; NoAction; }
	psa_implementation = as;
	}
	apply {
		indirect_with_selection.apply();
	}
}

Управление записями селектора действий при наличии отказов на каналах выходит за рамки PSA. Для быстрого восстановления нужны данные плоскости управления и этот вопрос будет решаться рабочей группой P4 Runtime API16.

7.13. Временные метки

Реализация PSA предоставляет значение ingress_timestamp для каждого пакета, входящего в блок управления Ingress, как поле структуры типа psa_ingress_input_metadata_t. Эта временная метка должна содержать время, близкое к моменту приема устройством первого бита пакета или (вариант) начала синтаксического анализа. Метка не включается автоматически в пакет на входе в блок управления Egress и желающая использовать ingress_timestamp в выходном коде программа P4 должна копировать ее в поле пользовательских метаданных, передаваемое выходному конвейеру. Предоставляется также метка egress_timestamp для каждого пакета, входящего в блок управления Egress, как поле структуры psa_egress_input_metadata_t.

Одним из ожидаемых применений временных меток является их сохранение в экземплярах таблиц или регистров (Register) для реализации контроля протокольных тайм-аутов, где миллисекундной точности достаточно для большинства протоколов. Другим ожидаемым вариантом применения является телеметрия INT17, где требуется точность порядка микросекунд и лучше для измерения задержек в очередях (передача кадра Ethernet jumbo размером 9 Кбайт по каналу 100 Гбит/с занимает 740 нсек).

Для таких приложений рекомендуется обновлять временные метки с периодом не более 1 мксек. Обновление в каждом цикле ASIC или FPGA обеспечивает разумное решение. Скорость обновления временных меток следует делать постоянной. Например, для этого не следует использовать простой подсчет тактов, поскольку тактовая частота устройства может динамически изменяться18.

Временные метки имеют тип Timestamp_t, который является bit<W>, а значение W задает реализация. Предполагается, что значения временных меток будут в течение некоторого времени повторяться в результате переполнения (wrap). Рекомендуется выбирать частоту обновления и число битов так, чтобы повтор значений меток происходил не чаще одного раза в час. Это позволит сделать метки полезными для указанных ниже применений.

  • Контроль тайм-аутов трафика hello и keep-alive, составляющих секунды или минуты.

  • Если временные метки включаются в метаданные без преобразования формата, многим внешним системам анализа данных могут потребоваться преобразования, например, для сравнения временных меток из разных устройств PSA. Этим системам потребуются разные формулы и/или параметры для учета цикличности временных меток или добавление ссылок на внешние источники временных данных. Чем длительней будут циклы временных меток, тем меньше будет объем таких дополнительных работ.

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

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

При генерации меток с разрядностью 32 каждую микросекунду продолжительность цикла составит 1,19 часа, а для 42-битовых меток с обновлением каждую наносекунду — 1,22 часа.

От реализации PSA не требуется синхронизация часов, например, по протоколу PTP19 или NTP20.

Фрагмент API плоскости управления, приведенный ниже, может быть частью P4 Runtime API.

// Сообщения TimestampInfo и Timestamp следует добавлять в oneof сообщений Entity.
// Сообщение TimestampInfo предназначено лишь для чтения и попытки изменить его
// не будут иметь эффекта, однако следует сообщать о них (ошибка).
message TimestampInfo {
	// Число битов типа Timestamp_t в устройстве.
	uint32 size_in_bits = 1;
	// Значение временной метки в этом устройстве обновляется
	// increments_per_period раз каждые period_in_seconds секунд.
	uint64 increments_per_period = 2;
	uint64 period_in_seconds = 3;
}
// Значение timestamp доступно для чтения и записи. Отметим, что при наличии
// значений меток в экземплярах таблиц или регистров они не будут обновляться
// в результате записи значения timestamp для устройства, которое 
// предназначено лишь для для инициализации и тестирования.
message Timestamp {
	bytes value = 1;
}

Для каждого пакета P, обрабатываемого входным и выходным конвейером с минимальной задержкой в буфере пакетов, гарантируется, что значение egress_timestamp будет таким же или чуть больше значения ingress_timestamp, заданного для пакета на входе. «Почти» в данном случае означает, что разность (egress_timestamp — ingress_timestamp) должна быть достаточно точной оценкой задержки в буфере пакетов, возможно нулевой, если эта задержка будет меньше интервала обновления меток.

Рассмотрим два пакета, которым одновременно (например, в один машинный такт) назначены временные метки — одному ingress_timestamp в начале входной обработки, другому — egress_timestamp в начале выходной. Эти метки могут отличаться на несколько десятков наносекунд (или один «тик» временных меток, если он больше) по причине практических сложностей синхронизации.

Напомним, что двоичные операции + и — для типа bit<W> в P4 определены с использованием арифметики без знака с учетом перехода через максимум (wrap-around). Таким образом, даже при переходе временных меток через максимум всегда можно вычислить разность между метками t1 и t2, используя выражение t2−t1 (если интервал превышает 2W «тиков», это будет псевдонимом результата). Например, если для меток применяется W >= 4 битов и t1 = 2W − 5, а t2 = 3, то t2 − t1 = 8. Таким образом не возникает потребности в условных операциях для вычисления интервала.

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

Другим примером являются приложения, которым требуется высокая точность с учетом всех битов временных меток, но плоскость управления и программа P4 проверяют все записи массива регистров, где хранятся эти временные метки, не чаще 1 раза в 5 секунд для предотвращения перехода через максимум. В этом случае программа P4 может отбросить старшие биты временных меток, чтобы оставшиеся биты переходили через максимум каждые 8 секунд и сохранять эти усеченные метки в экземпляре Register.

7.14. Дайджест пакета

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

Дайджест может включать любые данные плоскости управления. Поскольку программа P4 может иметь множество экземпляров Digest, каждый из которых передает свое содержимое, реализации PSA нужно различать дайджесты, созданные разными экземплярами. В PSA дайджест создается вызовом метода pack для экземпляра Digest. Аргументом вызова является включаемое в дайджест содержимое, которое часто является набором значений в структуре P4. Компилятор выбирает подходящий формат последовательной передачи содержимого дайджеста локальному программному агенту, который отвечает за доставку дайджеста в заданном спецификацией P4 Runtime API формате.

Программа PSA может создать множество экземпляров Digest в одном блоке управления IngressDeparser и применять не более одного вызова pack для каждого экземпляра в процессе работы этого блока управления. От реализации PSA не требуется поддержка применения внешнего блока Digest в блоке управления EgressDeparser.

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

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

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

extern Digest<T> {
	Digest();		/// Определяет поток сообщений для плоскости управления.
	void pack(in T data);	/// Отправка данных в поток.
	/*
	@ControlPlaneAPI
	{
		T data;			/// Если T - список, плоскость управления создает struct.
		int unpack(T& data);	/// Распакованные данные помещаются в T&, int - код возврата.
	}
	*/
}

Ниже представлен фрагмент примера, демонстрирующего применение дайджеста для уведомления плоскости управления для о новой комбинации Ethernet MAC и входного порта в принятом пакете.

struct mac_learn_digest_t {
	EthernetAddress srcAddr;
	PortId_t	ingress_port;
}
struct metadata {
	bool			send_mac_learn_msg;
	mac_learn_digest_t	mac_learn_msg;
}

// Это часть функциональности обычного моста Ethernet с обучением.
// Плоскость управления обычно задает одинаковые ключи для таблиц 
// learned_sources и l2_tbl. Записи в l2_tbl служат для поиска по 
// MAC-адресу получателя и совпадение дает выходной порт для пакета.
// Записи в learned_sources такие же, но действием для них служит
// NoAction. При отсутствии адреса в learned_sources разумно передать
// плоскости управления сообщение с MAC-адресом отправителя и номером
// принявшего пакет порта. Плоскость управления примет решение о 
// добавлении записи с MAC-адресом отправителя в обе таблицы и l2_tbl 
// далее будет передавать пакеты в ingress_port этого пакета.
// Это лишь простой пример, который не включает, например, лавинной
// рассылки, которую мост с обучением обычно применяет при отсутствии 
// в таблице MAC-адреса получателя.
control ingress(inout headers hdr,
		 inout metadata meta,
		 in psa_ingress_input_metadata_t istd,
		 inout psa_ingress_output_metadata_t ostd)
{
	action unknown_source () {
		meta.send_mac_learn_msg = true;
		meta.mac_learn_msg.srcAddr = hdr.ethernet.srcAddr;
		meta.mac_learn_msg.ingress_port = istd.ingress_port;
		// meta.mac_learn_msg передается плоскости управления
		// в блоке управления IngressDeparser.
	}
	table learned_sources {
		key = { hdr.ethernet.srcAddr : exact; }
		actions = { NoAction; unknown_source; }
		default_action = unknown_source();
	}
	action do_L2_forward (PortId_t egress_port) {
		send_to_port(ostd, egress_port);
	}
	table l2_tbl {
		key = { hdr.ethernet.dstAddr : exact; }
		actions = { do_L2_forward; NoAction; }
		default_action = NoAction();
	}
	apply {
		meta.send_mac_learn_msg = false;
		learned_sources.apply();
		l2_tbl.apply();
	}
}
control IngressDeparserImpl(packet_out packet,
			      out empty_metadata_t clone_i2e_meta,
			      out empty_metadata_t resubmit_meta,
		  	      out empty_metadata_t normal_meta,
			      inout headers hdr,
			      in metadata meta,
			      in psa_ingress_output_metadata_t istd)
{
	CommonDeparserImpl() common_deparser;
	Digest<mac_learn_digest_t>() mac_learn_digest;
	apply {
		if (meta.send_mac_learn_msg) {
			mac_learn_digest.pack(meta.mac_learn_msg);
		}
		common_deparser.apply(packet, hdr);
	}
}

8. Неделимость операций API плоскости управления

Все операции добавления, удаления и изменения таблиц должны быть неделимыми (atomic) относительно пересылки пакета. Т. е. для каждой табличной операции apply и каждой операции плоскости управления по добавлению, удалению или изменению записи в таблице операция apply должна выполняться так, будто изменения таблицы еще не началось, либо оно уже завершилось. Программе P4 никогда не следует вести себя так, будто операция плоскости управления выполнена частично.

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

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

Предположим, например, что таблица T имеет действие A со 100 битами (суммарно) параметров, а плоскость управления добавила в таблицу запись с ключом поиска K и действием A. Позднее плоскость управления обновила запись для ключа K, не меняя ключ, но изменив 100 битов параметров действия. Для каждого пакета, вызывающего apply для таблицы T и записи с ключом K, нужно выполнить действие A со старыми или новыми 100 битами параметров.

P4 Runtime API позволяет контроллерам группировать сообщения для выполнения нескольких операций в один прием, как описано здесь. В этом случае реализации PSA нужно лишь обеспечит неделимость каждой отдельной операции. Для последовательности операций добавления, удаления или обновления неделимость не требуется.

То же самое применимо ко всем операциям API плоскости управления с внешними блоками (extern), если в документации явно не указано иное. В частности, одиночным операциям ActionProfile и ActionSelector, таким как добавление в группу или удаление из нее, добавление или удаление пустой группы и изменение параметров действия, добавленного ранее в группу, должна обеспечиваться неделимость. Неделимыми также должны быть операции плоскости управления по чтению и записи отдельных элементов массива Register, кроме того они должны происходить до или после (но не в процессе) любого блока кода P4, помеченного аннотацией @atomic. В плоскости управления нет операций над Register, которые могут неделимо читать элемент, а затем записывать в него измененное значение.

Если нужно из программы P4 неделимо считать, изменить и записать обратно элемент массива Register, следует сделать так, чтобы операции чтения, изменения и записи в программе P4 выполнялись «пакетом», который плоскость управления может внедрить в плоскость данных (например, через операции packet in и packet в P4 Runtime API).

Высокоскоростная реализация PSA может обрабатывать сотни или тысячи пакетов между отдельными операциями плоскости управления. Имеются базовые методы «записи в таблицу из будущего в прошлое потока данных» (write tables from later to earlier in the data flow), которые иногда называют back to front или pointer flipping, используемые плоскостью управления для достижения эффекта, подобного обеспечению неделимости операций над последовательностью таблиц в процессе пересылки пакета. Имеются исследования таких методов в более общем контексте21.

A. Нерешенные вопросы

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

A.1. Селекторы действий

Параметр size в экземпляре action_selector определяет максимальное число элементов селектора. В некоторых случаях может оказаться полезным позволить контроллеру динамически выделять ресурсы для селектора или применять селекторы разных размеров на разных платформах, используя одну программу P4.

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

A.2. Обнаружение и контроль перегрузок

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

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

Желательно задать в PSA небольшой набор полей, которые будут служить входными данными для множества алгоритмов контроля перегрузок. Одним из вариантов является использование хэшированного идентификатора потока, часто реализуемого в форме хэш-функции от полей заголовка IP, таких как адреса получателя и отправителя, протокол IP и, возможно порты TCP/UDP для отправителя и получателя. С учетом того, что программируемые на P4 устройства могут обрабатывать не только пакеты IP, желательно найти механизм более общего назначения для устройств PSA.

A.3. Возможность полной реализации внутриполосной телеметрии

Одним из многообещающих применений программируемых на P4 сетевых устройств является внутриполосная телеметрия INT24. Хотя в PSA уже реализованы такие важные для телеметрии механизмы, как временные метки, еще не разработаны механизмы доступа к информации о загрузке каналов на выходных портах и заполнении очередей25.

A.4. Профили PSA

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

B. Реализация внешнего блока InternetChecksum

В RFC 1071 и RFC 1141 описан эффективный расчет контрольных сумм Internet, особенно для программных реализаций. Ниже приведены прототипы реализации методов для внешнего блока InternetChecksum с использованием синтаксиса и семантики P416, расширения цикла for и оператора return, возвращающего значение функции. Для экземпляра объекта InternetChecksum требуется как минимум внутреннее состояние в форме 16-битового вектора (sum в приведенном примере).

// Один из способов получить дополнение до 1 суммы двух
// 16-битовых значения.
bit<16> ones_complement_sum(in bit<16> x, in bit<16> y) {
	bit<17> ret = (bit<17>) x + (bit<17>) y;
	if (ret[16:16] == 1) {
		ret = ret + 1;
	}
	return ret[15:0];
}
bit<16> sum;
void clear() {
	sum = 0;
}
// Размер data должен быть кратным 16 битам
void add<T>(in T data) {
	bit<16> d;
	for (каждой 16-битовой части d из data) {
		sum = ones_complement_sum(sum, d);
	}
}
// Размер data должен быть кратным 16 битам
void subtract<T>(in T data) {
	bit<16> d;
	for (каждой 16-битовой части d из data) {
		// ~d - отрицание d в арифметике с дополнением до 1.
		sum = ones_complement_sum(sum, ~d);
	}
}
// Контрольная сумма Internet является дополнением до 1 суммы 
// дополнений до 1 соответствующих частей пакета. Указанные выше
// методы возвращают сумму дополнений до 1 в переменной sum.
// get() возвращает побитовой отрицание sum, которое является
// дополнением sum до 1.
bit<16> get() {
	return ~sum;
}
bit<16> get_state() {
	return sum;
}
void set_state(bit<16> checksum_state) {
	sum = checksum_state;
}

C. Пример реализации внешнего блока Counter

Приведенный ниже пример, в частности, функция next_counter_value служит лишь для иллюстрации и не требует его реализации в PSA. Формат хранения PACKETS_AND_BYTES также служит лишь примером. Реализации могут хранить состояние иначе, если API плоскости управления возвращает корректные значения счетчиков пакетов и байтов.

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

  • кольцевые (wrap around) счетчики;
  • счетчики с насыщением, «застывающие» при максимальном значении без сброса в 0.

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

Counter(bit<32> n_counters, PSA_CounterType_t type) {
	this.num_counters = n_counters;
	this.counter_vals = новый массив из n_counters элементов размера W;
	this.type = type;
	if (this.type == PSA_CounterType_t.PACKETS_AND_BYTES) {
		// Подсчет пакетов и байтов использует общее хранилище состояния.
		// Нужны ли отдельные конструкторы с дополнительным аргументом,
		// задающим размер счетчика байтов?
		W shift_amount = TBD;
		this.shifted_packet_count = ((W) 1) << shift_amount;
		this.packet_count_mask = (~((W) 0)) << shift_amount;
		this.byte_count_mask = ~this.packet_count_mask;
	}
}
W next_counter_value(Wcur_value, PSA_CounterType_t type) {
	if (type == PSA_CounterType_t.PACKETS) {
		return (cur_value + 1);
	}
	// Учитываемые в packet_len байты зависят от реализации.
	PacketLength_t packet_len = <размер пакета в байтах>;
	if (type == PSA_CounterType_t.BYTES) {
		return (cur_value + packet_len);
	}
	// Требуется тип PSA_CounterType_t.PACKETS_AND_BYTES.
	// В счетчике размера W младшие байты служат счетчиком байтов,
	// а старшие учитывают пакеты.
	// Это просто один из форматов хранения и реализация может иначе
	// хранить состояние packets_and_byte, если API плоскости данных
	// корректно возвращает значения счетчиков байтов и пакетов.
	W next_packet_count = ((cur_value + this.shifted_packet_count) &
				  this.packet_count_mask);
	W next_byte_count = (cur_value + packet_len) & this.byte_count_mask;
	return (next_packet_count | next_byte_count);
}
void count(in S index) {
	if (index < this.num_counters) {
		this.counter_vals[index] = next_counter_value(this.counter_vals[index], this.type);
	} else {
		// Значение counter_vals не обновляется при выходе индекса за
		// границы диапазона. Запись отладочных данных описана ниже.
	}
}

При выходе индекса за границы диапазона можно записывать дополнительную отладочную информацию:

  • число фактов выхода индекса за границы;

  • FIFO для первых N выходов индекса за границу (N определяется реализацией, например, 1);

  • рекомендуется также сохранять информацию о точке вызова в программе P4 метода count() с выходящим за границы индексом.

D. Обоснование архитектуры

D.1. Зачем нужна выходная обработка?

В чем польза от разделения обработки пакетов в коммутаторе на входную и выходную?

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

1. Изменение пакетов в последний момент

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

Но для каналов с переменной скоростью, например, Ethernet с управлением потоком данных с помощью кадров pause, в Wi-Fi при изменении качества сигнала или при наличии очередей по классам обслуживания со взвешенным планированием, невозможно предсказать в момент отправки пакета в очередь время его выхода из очереди. Задержка в очереди зависит от неизвестных событий в будущем, таких как получение кадров Ethernet или число и размер пакетов, поступающих в очереди с разным классом обслуживания.

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

2. Эффективность и гибкость групповой обработки

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

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

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

При такой организации multicast-обработки все еще сохраняется потребность в различной обработке разных копий одного пакета. Например, в копию для выходного порта 5 нужно поместить тег VLAN 7, а для порта 2 — VLAN 18. Аналогичная задача возникает при отправке групповых пакетов в туннели VXLAN, GRE и т. п. За счет изменения выходной обработки на уровне пакета логика репликации остается достаточно простой — создаются идентичные копии по завершении входного конвейера, различающиеся лишь неким уникальным идентификатором, позволяющим различать эти копии при выходной обработке.

D.2. Неизменность выходного порта в процессе выходной обработки

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

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

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

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

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

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

D.3. Входной сборщик и выходной анализатор

В P414 нет входного сборщика и выходного анализатора. Зачем они в PSA?

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

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

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

Ситуация с выходным сборщиком похожа. Делая его явным и отдельным блоком, вы получаете полный контроль над данными, включаемыми в пакет при отправке его в буфер. В P414 неявно предполагается, что все метаданные пакета, применяемые в выходном коде, передаются вместе с пакетом. Это можно сделать и в программах P416 для архитектуры PSA, но сейчас это должно быть явным. В PSA можно ограничить объем передаваемых с пакетом метаданных, что может быть важно для блоков ввода-вывода буфера пакетов.

E. Устройства PSA с несколькими конвейерами

В современных высокоскоростных сетевых устройствах применяются ASIC с тактовой частотой 1 — 2 ГГц. В приведенном ниже обсуждении предполагается частота 1 ГГц, но все рассмотренные аспекты линейно масштабируются по частоте.

Обычно часть сетевого ASIC проектируется так, чтобы обработка нового пакета начиналась один раз в каждом такте и заканчивалась в каждом такте. Задержка от начала до завершения обработки может составлять сотни циклов тактирования. Таблицы P4 в таких ASIC обычно размещаются в памяти TCAM и SRAM. TCAM позволяет выполнять 1 поиск за такт, а SRAM — 1 операцию чтения или записи. Хотя имеются многопортовые системы SRAM, позволяющие выполнять несколько операций чтения и/или записи за один такт, они существенно проигрывают по размеру и потребляемой мощности по сравнению с однопортовыми. При создании многопортовых систем TCAM рост размеров и потребляемой мощности будет еще больше, чем для многопортовых SRAM. Типовым способом повышения скорости поиска в TCAM является параллельная работа, когда создается несколько копий TCAM, что обеспечивает линейный рост размеров и потребляемой мощности.

По этом причинам для создания коммутационных ASIC, обрабатывающих пакеты в N быстрее тактовой частоты (например, 2 миллиарда пакетов в секунду при частоте 1 ГГц), наиболее простым решением является параллельная обработка пакетов26 с созданием N конвейеров27, каждый из которых обрабатывает 1 миллиард пакетов в секунду. Созданные на основе такого подхода устройства PSA обычно будут включать N входных конвейеров и N выходных. Обычно к каждому конвейеру жестко привязывается множество физических портов ASIC, например, в устройстве с 32 портами 100G Ethernet можно привязать порты 0 — 15 к конвейеру 0, а порты 16 — 31 к конвейеру1. Все пакеты, принятые портами 0 — 15, обрабатываются входным конвейером 0, затем передаются в буфер пакетов (если не отброшены на входе),а после этого — в выходной конвейер 0, если они направлены в выходные порты 0 — 15, или в выходной конвейер 1, если направлены в порты 16 — 31. В таком устройстве обычно требуется применять одну и ту же программу P4 в каждом из N входных и выходных конвейеров.

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

Независимо от описанного выше подхода, применение таблиц в P4 выполняется в параллельном режиме, поскольку конвейеры могут работать совершенно независимо один от другого без обмена информацией между собой (имеющееся исключение описано ниже). То же относится к большинству внешних блоков PSA, например, ActionProfile, ActionSelector, Checksum, Digest, Hash, Random. Общим у таблиц P4 и этих внешних элементов является то, что программы P4 либо совсем не могут менять их состояние (например, таблицы, ActionProfile, ActionSelector), либо могут могут менять его лишь так, что это не влияет на обработку других пакетов (например, Checksum, Digest, Hash). Блок Random является особым случаем — обновление состояния генератора псевдослучайных чисел может влиять на обработку других пакетов, но обычно это связано со способом применения таких чисел (например, случайный выбор пакета для маркировки или отбрасывания в алгоритме RED).

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

Рассмотрим устройство с поддержкой независимых измерителей в каждом конвейере. Если нужно учесть все пакеты, соответствующие записи таблицы X, но не более Y байт/сек, можно выполнить координацию состояний между конвейерами, например, с помощью протоколов когерентности кэша, обычно реализованных с многоядерных CPU, или рециркуляции пакетов в общий конвейер, где сохраняется состояние измерителя. Оба варианта имеют низкую производительность (по крайней мере в части случаев) и сложны в реализации. Коммутаторы обычно поддерживают независимые состояния измерителей в каждом конвейере, не координируя их. Эта проблема не специфична для коммутаторов и относится к категории доступа к изменяемому состоянию распределенной системы, что связано не только с вопросами точности, но и с проблемой производительности.

Внешний блок Register имеет более общее назначение по сравнению с регистрами и для него характерны те же проблемы разделения состояний между множеством конвейеров. Рекомендуется обсудить эти вопросы с производителем устройства PSA, если предполагается их влияние на работу программы P4. Если устройство PSA не согласует состояния автоматически, следует применять общую стратегию, представленную выше для измерителей — воспринимать независимое поведение регистров каждого конвейера и рециркулировать нужные пакеты в конвейер, поддерживающий общее состояние.

Отметим, что предложенное свойство таблицы psa_idle_timeout обеспечивает способ использования операций apply для обновления состояний таблиц P4. Для каждой записи таблицы требуется по меньшей мере 1 бит для представления момента последнего совпадения с записью и это значение обновляется при каждой операции apply. Если это состояние в таблице с данной опцией не согласуется автоматически между конвейерами, значения в разных таблицах могут различаться. Запись с ключом X в одном конвейере может оставаться неиспользуемой дольше заданного тайм-аута, тогда как в других конвейерах она может применяться чаще. Одним из возможных решений этой проблемы для устройства PSA и зависящей от реализации плоскости управления является явное указание плоскости управления наличия множества конвейеров, например, путем назначения каждому конвейеру, таблице и внешнему блоку своего имени.

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

F. Упорядочение пакетов

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

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

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

Рекомендация 3. Индивидуальные пакеты PRE (т. е. те, которые идут по пути «поместить в очередь» в псевдокоде параграфа 6.2. Поведение пакетов по завершении входной обработки), принятые из одного порта, прошедшие входной конвейера однократно (без рециркуляции и повторного представления), переданные а PRE с одним значением класса обслуживания (class_of_service) и адресованные в один выходной порт, следует обрабатывать с том же порядке, в котором они пришли на входную обработку.

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

Если реализация следует рекомендациям 1 — 3, индивидуальный трафик с одним классом обслуживания будет сохранять относительный порядок пакетов при прохождении через устройство.

Рекомендация 4. Рассмотрим групповые пакеты PRE (пакеты, следующие по пути «создается клон» в псевдокоде параграфа 6.2. Поведение пакетов по завершении входной обработки), приходящие через один входной порт, проходящие входную обработку однократно и передаваемые в PRE с одинаковыми парами (class_of_service, multicast_group). Копии одного исходного пакета, адресованные в один выходной порт и имеющие одинаковые пары (egress_port, instance), следует обрабатывать на выходе в порядке их входной обработки.

Групповые пакеты с разными значениями class_of_service не рассматриваются по причине наличия в PRE раздельных очередей для разных классов обслуживания.

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

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

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

Ниже приведены некоторые основания для рекомендаций этого приложения.

  1. Ожидания хостов.

    Хотя в протоколе IP нет строгих требований в части порядка пакетов, передаваемых от одного хоста к другому, имеются широко распространенные реализации TCP, для которых производительность работы в реальном масштабе времени значительно снижается при нарушении порядка доставки пакетов в сети. Для решения этой проблемы было выполнено множество исследований и разработок (например, современные реализации Linux TCP, начиная с 2011 г., когда было выпущено ядро 2.6.35, значительно устойчивей своих предшественников), однако остается еще много реализаций TCP, страдающих от нарушения порядка. Примеры можно найти в работке Kandula и соавторов28, где проведено исследование повышения устойчивости TCP к нарушениям порядка доставки.

    Такие реализации TCP считают подтверждения с повторяющимися кумулятивными порядковыми номерами вероятным указанием на потерю пакетов в сети и сокращают окно передачи для предотвращения перегрузок в сети.

    Хотя приложениям UDP также нужно быть готовыми к возможному нарушению порядка пакетов в сети, некоторые из них ведут себя некорректно при таком нарушении29.

    Упомянутые выше причины служат основанием для использования хэш-значений полей заголовков пакетов (таких как IP-адреса отправителя и получателя, номера портов TCP или UDP) при выборе между равноценными путями ECMP30 и каналами LAG. Такой выбор между параллельными путями помогает сохранить порядок пакетов за счет снижения равномерности распределения нагрузки. Если бы внутренняя реализация сетевого устройства меняла порядок пакетов, это стало бы еще одной причиной его нарушения.

  2. Реализация протоколов с состояниями.

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

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

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

G. Поддержка пустых групп в селекторах действий

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

Некоторые пользователи P4 выразили заинтересованность в предоставлении возможности клиенту P4Runtime (контроллер) удалять последний элемент группы селектора действий и получать в результате предсказуемое поведение плоскости данных.

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

Для полной поддержки пустых групп действий следует выполнять приведенные ниже требования.

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

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

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

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

Это поведение можно реализовать с помощью дополнительной логики в сервере P4Runtime (иногда называемом агентом). Идея состоит в том, что агент получает пустое действие группы со значениями параметров действий, например, из скомпилированного представления программы P4.

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

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

Агент может реализовать эти команды, внеся в плоскость управления указанные ниже команды.

  1. Добавить в G новый элемент, являющийся пустым действием группы. В результате группа G будет кратковременно включать 2 элемента.
  2. Удалить из группы G элемент, для которого контроллер запросил удаление. В результате имеющаяся в плоскости данных группа G будет включать единственный элемент, содержащий пустое действие группы, поэтому все пакеты, использующие G будут выполнять это действие.

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

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

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

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

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

Например, в отмеченном ранее варианте выбора порта LAG тиеется лишь одно действие для таблицы lag, как показано ниже.

action set_output_port (PortId_t p) {
	user_meta.out_port = p;
}
ActionProfile(128) ap;
table lag {
	key = {
		// ... поля ключа ...
	}
	actions = { set_output_port; }
	psa_implementation = ap;
}
control cIngress (inout headers hdr,
		   inout metadata user_meta,
		   in psa_ingress_input_metadata_t istd_meta,
		   inout psa_ingress_output_metadata_t ostd_meta)
{
	apply {
		// ... предшествующий код входного конвейера ...
		lag.apply();
		send_to_port(ostd_meta, user_meta.out_port);
		// ... последующий код входного конвейера ...
	}
}

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

Подход 1. Использование недействительного номера порта.

Выбирается значение PortId_t, которое не соответствует ни одному физическому порту устройства31, и применяется для пустого действия в пустой группе. В примере кода после lag.apply добавлен оператор if для проверки этого значения.

apply {
	// ... предшествующий код входного конвейера ...
	lag.apply();
	if (user_meta.out_port == PORT_INVALID_VALUE) {
		ingress_drop(ostd_meta);
	} else {
		send_to_port(ostd_meta, user_meta.out_port);
	}
	// ... последующий код входного конвейера ...
}

Подход 2. Добавление дополнительных параметров действия.

В этом случае добавляется 1-битовый параметр, указывающий отбрасывание пакета. Сохраняется необходимость использования оператора if после применения таблицы (apply).

action set_output_port (PortId_t p, bit<1> drop) {
	user_meta.out_port = p;
	user_meta.drop = drop;
}
// ...
	apply {
		// ... предшествующий код входного конвейера ...
		lag.apply();
		if (user_meta.drop == 1) {
			ingress_drop(ostd_meta);
		} else {
			send_to_port(ostd_meta, user_meta.out_port);
		}
	// ... последующий код входного конвейера ...
	}

В любом случае реализация может также поддерживать применение оператора if внутри действия set_output_port, не PSA не требует такой поддержки.

H. История выпусков

 

Выпуск

Дата

Описание изменений

1.0

1 марта 2018 г.

Исходный выпуск

1.1

22 ноября 2018 г.

Версия 1.1, см. ниже.

 

H.1. Изменения в версии 1.1

H.1.1. Численные преобразования между P4Runtime API и плоскостью данных

После выпуска PSA v1.0 было проведено несколько встреч рабочей группы по вопросам численных преобразования между значениями PortId_t (а также ClassOfService_t и возможно других значений в будущем). В PSA v1.1 отражены принятые решения.

  • 4.1. Определения типов PSA;

  • 4.4. Представление данных в плоскости управления и данных.

H.1.2. Возможность создания множества копий в сеансе клонирования

В PSA v1.0 запросы на клонирование ограничены созданием одной копии, передаваемой в выходной порт. PSA v1.1 позволяет настроить сеанс клонирования путем задания пар (egress_port, instance), подобно настройке multicast-групп.

  • 6.2. Поведение пакетов по завершении входной обработки;

  • 6.4.5. Групповая адресация и клоны;

  • 6.5. Поведение пакетов по завершении выходной обработки;

  • 6.8. Клонирование пакетов.

H.1.3. Добавлено свойство таблицы psa_idle_timeout

Добавление этого свойства в PSA v1.1 согласовано с его поддержкой в P4Runtime API. Использование этого свойства помогает разработчикам P4 указать, что таблица должна поддерживать состояние, указывающее время последнего совпадения для каждой записи, а в случае отсутствия совпадений в течение установленного плоскостью управления периода, передавать контроллеру уведомление.

  • 7.2.1. Уведомление о тайм-ауте для записи таблицы.

H.1.4. Добавлено свойство таблицы psa_empty_group_action

PSA v1.0 не задает поведения таблиц с реализацией ActionSelector для случаев, когда пакет соответствует записи, настроенной с пустой группой селектора действий. PSA v1.1 рекомендует (но не требует) от таких реализаций поддержки нового свойства таблиц psa_empty_group_action, значение которого указывает действие, выполняемое в таких ситуациях.

  • 7.12. Селекторы действий.

H.1.5. Прочие изменения

В PSA v1.0 поддержка внешнего блока Digest требовалась в блоках управления IngressDeparser и EgressDeparser. Сейчас она не требуется для блока EgressDeparser.

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

H.1.6. Изменения в файле psa.p4

  • Изменения в соответствии с численными преобразованиями P4Runtime API для типов PortId_t и ClassOfService_t.

  • Исключен устаревший внешний блок ValueSet, поскольку конструкция value_set была добавлена в спецификацию P416 версии 1.1.0.

  • Исправлены несколько опечаток в комментариях к API плоскости управления.

  • Исключен макрос #define PSA_SWITCH с аргументами, поскольку спецификация P416 не требует от препроцессора P416 поддержки таких макросов.

H.1.7. Изменения в примерах программ PSA из каталога p4-16/psa/examples

  • Небольшие изменения для приведения в соответствие с последними изменения в численном преобразовании для типа PortId_t в P4Runtime API.

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

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

nmalykh@protocols.ru

1Portable Switch Architecture.

2Packet buffer and Replication Engine — машина буферизации и репликации пакетов.

3Buffer Queuing Engine — машина очередей.

4Предполагается, что включаемые файлы psa.p4 для разных платформ будут в основном похожи один на другой. Кроме различий в размерах для типов PSA ожидаются различия в аннотациях блоков extern и п. п., позволяющие компилятору P4 для платформы выполнить свою работу.

5P4 Runtime API определяется как файл Google Protocol Buffer (protobuf) .proto, описание которого доступно по ссылке https://github.com/p4lang/p4runtime.

6P4 Runtime API определяется как файл Google Protocol Buffer .proto, описание которого доступно по ссылке https://github.com/p4lang/p4runtime.

7Хотя 10 Мбит не кажется большим объемом для компьютеров с памятью в сотни Гбайт, скоростные реализации PSA являются ASIC, где таблицы хранятся во встроенной памяти (как кэш-память обычных CPU). Intel i9-7980XE (2017 г.) имеет кэш-память L3 198 Мбит, используемую ядрами CPU. В процессорах Intel Core седьмого поколения, выпущенных в 2017 г, с памятью не меньше 100 Мбит L3-кэша стоимость составляет около $9/Мбит (https://en.wikipedia.org/wiki/List_of_Intel_microprocessors).

8С открытом компиляторе P4 p4c планируется поддержка опции для включения численных преобразований дополнительных типов без изменения программ P4 или включаемого файла psa.p4. Эти типы будут указываться по именам.

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

10TBD: Неясно, всегда ли минимальный размер данных составляет 46 байтов (64 байта минимального кадра Ethernet за вычетом 14 байтов заголовка 14 и 4 байтов CRC) или реализация может не включать некоторые байты.

11Random Early Detection — упреждающее отбрасывание случайного пакета.

12Approximate Fair Dropping — сравнительно беспристрастное отбрасывание.

13Link Aggregation Group — группа агрегирования каналов.

14Priority code point — код приоритета.

15Differentiated service code point — код дифференцированного обслуживания

16P4 Runtime API определяется как файл Google Protocol Buffer (protobuf) .proto, описание которого доступно по ссылке https://github.com/p4lang/p4runtime.

17In-band Network Telemetry — телеметрия по основному каналу связи, http://p4.org/p4/inband-network-telemetry

21Pavol Cerny, Nate Foster, Nilesh Jagnik, and Jedidiah McClurg, «Consistent Network Updates in Polynomial Time». International Symposium on Distributed Computing (DISC), Paris, France, September 2016.

23Approximate Fair Drop.

24In-band Network Telemetry, http://p4.org/p4/inband-network-telemetry

27Здесь и в спецификации P4 термин конвейер (pipeline) относится к части реализации P4, обеспечивающей, например, поведение блоков IngressParser, Ingress, затем IngressDeparser в PSA. Это принято в P4, хотя следует отметить наличие других аппаратных решений, которые реализуют функции конвейера иначе, например, в наборе параллельно работающих ядер CPU, каждое из которых обрабатывает свой пакет.

28S.Kandula, D. Katabi, S. Sinha, and A. Berger, «Dynamic load balancing without packet reordering», ACM SIGCOMM Computer Communication Review, Vol. 37, No. 2, April 2007,

30Equal Cost Multi Path.

31TBD. Возможно для такого порта следует определить имя, но в настоящее время PSA не включает такого определения.