1 ПОДГОТОВЛЕН Федеральным государственным бюджетным образовательным учреждением высшего образования "Санкт-Петербургский государственный университет телекоммуникаций им. проф. М.А. Бонч-Бруевича" (СПбГУТ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 апреля 2025 г. N 8-пнст

4 Настоящий стандарт является модифицированным по отношению к проекту международного стандарта ITU-T TR.NCDP "Протокол сетевого кодирования для многоадресной передачи данных" (ITU-T TR.NCDP "Session layer network coding protocol for multicast data transmission", MOD) путем изменения отдельных фраз (слов, значений показателей, ссылок), которые выделены в тексте курсивом.

Наименование настоящего стандарта изменено относительно наименования указанного проекта международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

Сопоставление структуры настоящего стандарта со структурой примененного в нем проекта международного стандарта приведено в дополнительном приложении ДА

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

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

Задачами разработки протоколов и стандартов сетевого кодирования в настоящее время активно занимаются такие организации, как рабочая группа инженерной поддержки сети Интернет (Internet Engineering Task Force, IETF) и Международный союз электросвязи (МСЭ) (International Telecommunications Union, ITU).

В настоящем стандарте представлено описание протокола сетевого кодирования NCDP для использования его в системах доставки контента.

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

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

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

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

В настоящем стандарте применен следующий термин с соответствующим определением:

2.1 системы передачи с сетевым кодированием: Системы передачи данных, в которых операции кодирования пакетов данных выполняются как на передающем узле, так и на промежуточных маршрутизирующих узлах.

Примечание - См. [1].

В настоящем стандарте применены следующие сокращения:

DCCP - протокол контроля перегрузки дейтаграмм (Datagram Congestion Control Protocol);

ID - идентификатор (Identifier);

IETF - группа инженерной поддержки сети Интернет (Internet Engineering Task Force);

IGMP - протокол управления групповой передачей данных (Internet Group Management Protocol);

IP - протокол межсетевого взаимодействия (Internet Protocol);

IPTV - телевидение с передачей данных по протоколу IP (Internet Protocol Television);

MLD - протокол обнаружения получателей групповой рассылки (Multicast Listener Discovery);

NCDP - протокол многоадресной передачи с сетевым кодированием (Network Coding Datagram Protocol);

OSI - модель взаимодействия открытых систем (Open Systems Interconnection);

PIM - групповая рассылка, не зависящая от протокола (Protocol Independent Multicast);

UDP - протокол пользовательских датаграмм (User Datagram Protocol).

В примере, рассмотренном на рисунке 1, компьютеры-адресаты R₁, R₂ и R₃ должны получить от источника S одну и ту же информацию. При последовательной одноадресной передаче, показанной на рисунке 1 а), источник S один за другим отправляет три отдельных пакета P₁, P₂ и P₃, которые маршрутизируются независимо и в итоге достигают получателей за разное время. Предполагается, что началом отсчета будет время отправки первого пакета P₁ от сервера-источника. Само время измеряют условными шагами передачи - интервалами времени передачи пакета между парами сетевых узлов. Тогда первый адресат R₁ получит пакет P₁ через четыре шага, второй адресат R₂ - через пять шагов, а третий адресат R₃ - через шесть шагов.

При многоадресной передаче, представленной на рисунке 1 б), источник S отправляет один пакет P сразу группе адресатов R₁, R₂ и R₃. В итоге каждый адресат получает пакет за одно и то же время, равное условным четырем шагам от начала передачи.

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

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

В общем случае передачи N пакетов процедура сетевого кодирования для формирования общего пакета представлена формулой

где "*" - это обратимая математическая операция или совокупность операций, лежащих в основе сетевого кодирования и обладающих свойством (P * P = E), где E - это единичный элемент - такой, что P * E = P.

Для восстановления любого из пакетов P_i необходимо знать общий пакет P_NC и оставшиеся N - 1 исходных пакетов. К примеру, для восстановления (декодирования) пакета P₁ потребуется провести следующий расчет:

Следует рассмотреть в качестве примера случай двух источников. Берут два пакета P₁ и P₂. В простейшем случае результат их сетевого кодирования представлен пакетом

где "" - это оператор поразрядного сложения по модулю 2, он же операция XOR.

Таким образом, зная закодированный пакет P_NC и один из исходных пакетов, возможно восстановить второй исходный пакет. Например, если известны P_NC и P₁, то

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

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

где "" - операция конкатенации массивов данных пакетов P₁ и P₂.

На рисунке 2 показан пример выполнения операции по формуле (5) и обратного преобразования согласно формуле (4). Все данные представлены в 16-ричной системе счисления. Пакет P₁ имеет длину L₁ = 5 байт и равен [23 A5 82 34 D2]. Пакет P₂ имеет длину L₂ = 8 байт и равен [4F 28 56 AE D6 EA 39 48].

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

На рисунке 3 показан пример выполнения операции по формуле (6) при константе A = 76_hex.

Еще одним вариантом наращивания длины меньшего пакета является его зацикливание при помощи конкатенации в циклическом регистре сдвига. То есть меньший пакет как бы наращивается до длины L₂ большего пакета P₂ использованием собственных младших разрядов.

Пример вычисления по формуле (7) показан на рисунке 4.

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

Пример вычисления по формуле (8) показан на рисунке 5.

При анализе механизма сетевого кодирования традиционно рассматривают передачу в сети с топологией "бабочка", представленной на рисунке 6. Топология сети содержит два узла-источника S₁ и S₂, которые должны одновременно передать пакеты данных P₁ и P₂ сразу двум узлам-адресатам R₁ и R₂. Маршрутизацию пакетов данных от узлов-источников к узлам-адресатам обеспечивают шесть транзитных маршрутизирующих узлов - от G_A до G_F. Маршруты пакетов в сети приведены в таблице 1.

На рисунке 6 а) показано, что при обычной многоадресной передаче без сетевого кодирования пакеты P₁ и P₂ достигают узлов R₁ и R₂ неодновременно. Узел R₁ получает оба пакета условно через пять шагов, а узел R₂ - через шесть, т.е. возникает задержка. Это происходит за счет того, что на участке G_C - G_D пакеты передаются последовательно. В случае применения сетевого кодирования, показанном на рисунке 6 б), на участке G_C - G_D передается сразу линейная комбинация пакетов P_NC, вычисленная по формуле (3). Поэтому узлы R₁ и R₂ получают оба пакета одновременно за пять шагов.

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

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

Ромбовидная топология имеет различные варианты реализации. В настоящем стандарте рассматривается вариант ромбовидной топологии, в которой каждая из сторон ромба относится к одной пользовательской подсети, как показано на рисунке 7 б). Узлы - источники сигнала S₁ и S₂ относятся к верхним подсетям N₁ и N₂, в которые входят пары маршрутизаторов (G₁, G₂) и (G₁, G₃) соответственно. Узлы-адресаты R₁ и R₂ принадлежат нижним сетям N₃ и N₄, в которые входят пары маршрутизаторов (G₂, G₄) и (G₃, G₄) соответственно. Внутренняя подсеть N₃ образует дополнительный маршрут между маршрутизаторами G₁ и G₄. Маршруты пакетов в сети приведены в таблице 2.

На рисунке 7 б) представлена многоадресная передача пакетов от источников S₁ и S₂ адресатам R₁ и R₂ без применения сетевого кодирования. На рисунке 7 в) показана передача пакетов с сетевым кодированием на маршрутизаторе G₁ и декодированием на узлах-адресатах. Сравнивая представленные варианты передачи, можно увидеть, что, как и в случае с топологией "бабочка", сетевое кодирование позволяет выиграть время передачи одного пакета на участке G₁ - G₄. При простой многоадресной передаче для получения адресатами R₁ и R₂ пакетов P₁ и P₂ требуются четыре шага, а с сетевым кодированием - три шага.

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

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

Сеансовая часть взаимодействия, в том числе управление соединением и нумерация пакетов, возлагается на протокол сетевого кодирования NCDP.

Многоадресная передача в рамках сети реализуется на основе групповых адресов межсетевого протокола IP. Для обеспечения записи адресатов в группы и уведомления маршрутизаторов о прохождении групповых пакетов должны использоваться либо протоколы управления групповой передачей PIM, IGMP (для IPv4) и MLD (для IPv6), либо служебные пакеты самого протокола NCDP.

Структура заголовка NCDP показана на рисунке 8 а). Заголовок состоит из фиксированной части, используемой для всех пакетов NCDP, и вариативной, зависящей от типа пакета и значений флагов в фиксированной части.

Поле "Тип пакета" (8 бит) определяет его назначение. Идентификатор (ID) сеанса (16 бит) служит для того, чтобы различать пакеты разных групповых рассылок NCDP друг от друга. Флаги (8 бит) указывают на конкретные настройки при передаче пакетов и могут зависеть от типа пакета. Обязательным является флаг IP, который определяет версию сетевого протокола IP - IPv4 или IPv6. В зависимости от этого поля адресов источника в вариативной части заголовка будут иметь разный размер.

В протоколе используется три типа пакетов:

- тип 1 - пакет данных. Передается от источника до адресата. При передаче подвергается процедуре сетевого кодирования;

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

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

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

Заголовок пакета управления передачей протокола NCDP представлен на рисунке 9 в). Заголовок содержит IP-адрес источника информации. Для указания начала/конца передачи используется флаг SF обязательной части заголовка: 1 - обозначает начало передачи, 0 - ее конец.

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

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

Общая блок-схема порядка обработки заголовка управляющего пакета NCDP представлена на рисунке 9.

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

Если флаг SF равен 0, то проверяется наличие активного сеанса передачи для этого ID. Если такой сеанс открыт, то источник информации помечается как выключенный. Если это был последний источник для этого сеанса, то сеанс завершается, а ранее выделенные для него ресурсы освобождаются. Если сеанс для полученного ID отсутствует, то такой пакет принимается ошибочным и отбрасывается.

Блок-схема обработки пакетов данных на узле-кодере представлена на рисунке 10.

При обработке пакета данных изначально считывается идентификатор сеанса. Далее проводится проверка наличия открытого сеанса для этого ID. Если сеанс отсутствует, то пакет просто ретранслируется далее согласно правилам маршрутизации для используемой группы мультивещания. Если сеанс с данным ID открыт, то пакет обрабатывается дальше. Проводится проверка флага NC. Если флаг NC = 1, то этот пакет уже закодирован ранее и, следовательно, ретранслируется далее согласно правилам маршрутизации. Если флаг NC = 0, то проводится проверка количества активных источников информации. Если источник информации только один, то пакет ретранслируется далее. Если источников несколько, то в этом случае возможно выполнить процедуру сетевого кодирования и полученный пакет записывается в кольцевой буфер памяти, соответствующий IP-адресу источника . Как только в буферах памяти появляются два пакета, принадлежащих разным источникам, выполняется процедура сетевого кодирования и сформированный закодированный пакет отправляется далее.

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

Порядок обмена пакетами протокола NCDP между узлами-источниками и адресатами на основе упрощенной схемы сети представлен на рисунке 12 а). Схема содержит два узла-источника S₁ и S₂, маршрутизирующий узел G_C, на котором выполняется сетевое кодирование, и один из узлов-адресатов R₁. Поскольку прочие маршрутизаторы в стандартной архитектуре "бабочка" выполняют только маршрутизацию трафика без обработки, они не рассматриваются. Обмен трафиком с узлом-адресатом R₂ будет выполняться симметрично, поэтому он также не приводится.

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

Далее узлы-источники отправляют управляющие пакеты с флагом SF = 1, сигнализирующие о начале передачи и сообщающие маршрутизатору G_C и узлу-адресату R₁ о необходимости выделить ресурсы для обработки пакетов данной сессии.

Ниже стартового сообщения показан пример передачи пакета с данными - передача одной пары пакетов P₁ и P₂. Дальнейшая передача пакетов данных будет проводиться аналогично.

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

Стартовый и финальный управляющие пакеты маршрутизатор G_C перенаправляет только от тех узлов-источников, для которых он получал запрос данных от адресата. В примере на рисунке 12 б) маршрутизатор G_C получил запрос данных от R₁ для S₂. Запрос данных для S₁ прошел мимо G_C по прямому маршруту R₁ - S₁ (R₁ - G_E - G_A - S₁ из полной схемы сети "бабочка"). Следовательно, управляющие пакеты от S₁, приходящие на G_C, не будут ретранслироваться на R₁.