Надежная многоадресная рассылка, ориентированная на NACK

NACK-ориентированная надежная многоадресная рассылка (NORM) — это транспортного уровня, интернет-протокол предназначенный для обеспечения надежной транспортировки в группах многоадресной рассылки в сетях передачи данных. Официально он определен Инженерной группой Интернета (IETF) в запросе комментариев (RFC) 5740 , который был опубликован в ноябре 2009 года.

NORM работает поверх протокола пользовательских дейтаграмм (UDP) и обеспечивает надежную связь на основе отрицательного подтверждения (NACK) и механизма выборочного автоматического запроса повторения (ARQ), в отличие от подхода положительного подтверждения (ACK), который используется в стандартном управлении передачей. Протокол (TCP) использует. Другими словами, получатели, использующие NORM, отправляют обратную связь только в том случае, если они не получили пакет, в отличие от модели TCP, где получатели регулярно подтверждают получение пакета как часть работы протокола. Это позволяет NORM поддерживать крупномасштабные группы приемников.

Для поддержки дальнейшей масштабируемости NORM также использует кодирование со стиранием пакетов с использованием кодов прямого исправления ошибок (FEC) в сочетании с подавлением избыточной обратной связи NACK от группы получателей. Кроме того, NORM можно настроить для работы с «тихими получателями», полагаясь на кодирование стирания пакетов для обеспечения высокой надежности доставки, таким образом работая как протокол только для широковещательной передачи. FEC можно настроить для использования либо реактивно (с приемниками NACKing), либо упреждающе (тихие приемники), либо гибридным способом, позволяющим найти компромисс между задержкой и сетевыми издержками.

Помимо поддержки надежного транспорта, NORM также обеспечивает TCP-совместимое управление перегрузкой , а также сквозное управление потоком . В отличие от TCP, который использует механизм ACK для контроля перегрузки и управления потоком, NORM использует отдельные механизмы для каждого из них. Это позволяет использовать самые разнообразные конфигурации для удовлетворения различных потребностей приложений в доставке данных.

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

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

Фон

В сетевой модели TCP/IP транспортный уровень сети (уровень 4) отвечает за надежную транспортировку данных. Протокол TCP является основным средством обеспечения надежной одноадресной передачи (точка-точка). TCP делает это через механизм ACK.

При использовании механизма ACK пакеты данных последовательно нумеруются, и отправитель не отправляет пакет последовательно до тех пор, пока не получит подтверждение (ACK) от получателя о том, что предыдущий пакет был успешно получен. Если отправитель не получает ACK по истечении указанного периода времени, он повторно отправляет связанный пакет. Отправитель будет продолжать делать это до тех пор, пока не получит ACK (хотя после определенного момента отправитель предположит, что соединение потеряно, и прекратит сеанс). Это во многом аналогично тому, как человек-слушатель кивает головой и говорит «ага» в разговоре один на один между людьми. (Родственный протокол TCP, UDP, этого не делает. UDP просто отправляет пакеты данных по сети наилучшим образом и предполагает, что пакеты хорошо приняты.)

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

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

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

MDP был прямым предшественником NORM, первоначальный проект IETF был опубликован в ноябре 1996 года. Национальное управление по аэронавтике и исследованию космического пространства (НАСА) приняло MDP для надежной передачи файлов во время космических полетов. и армия США использовала его для обмена сообщениями тактических групп в своей системе Force Battle Command Brigade and Below (FBCB2).

Примерно в то же время разрабатывались несколько других подходов к надежной многоадресной передаче: а в апреле 1999 года IETF учредил Рабочую группу по надежной многоадресной передаче (RMTWG) для стандартизации надежной многоадресной передачи.

RMTWG придерживалась стратегии разработки строительных блоков и экземпляров протоколов. Эта стратегия позволила избежать использования протокола «один размер подходит всем», который, в свою очередь, мог бы поддерживать большое количество приложений и типов приложений, которые могла бы поддерживать надежная многоадресная рассылка.

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

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

• Протокол на основе NACK
• Протокол асинхронного многоуровневого кодирования

В июле 2005 года строительные блоки протокола на основе NACK и создание экземпляров протокола были представлены как «экспериментальные» в RFC 3940, а в ноябре 2009 года «NACK-ориентированный надежный многоадресный транспортный протокол (NORM)» был одобрен в RFC 5740.

RMTWG была упразднена в сентябре 2013 года.

НОРМ архитектурные конструкции

Следующие архитектурные конструкции определены в RFC 5740, раздел 2, Определение архитектуры.

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

NORM Объект относится к одному из трех различных типов объемных данных, передаваемых в сообщении NORM:

• NORM_OBJECT_DATA
• NORM_OBJECT_FILE
• NORM_OBJECT_STREAM

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

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

NORM Сеанс относится к обмену информацией между двумя или более сетевыми хостами с использованием NORM. Обычно сеанс NORM происходит с использованием заранее определенных IP-адресов и номеров портов , которые обычно связаны с групповыми IP-адресами многоадресной рассылки , определенными до сеанса. Эти адреса могут быть определены с использованием других протоколов, таких как протокол описания сеанса (SDP) [RFC 4566] или протокол объявления сеанса (SAP) [RFC 2974]. Хотя NORM был специально разработан для многоадресной групповой связи, он также поддерживает одноадресную связь.

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

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

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

Структура сообщения НОРМ

NORM имеет два общих класса сообщений: сообщения отправителя и получателя, которые определены в разделе 4 RFC 5740 «Форматы сообщений NORM». Типы сообщений отправителя NORM: NORM_DATA, NORM_INFO и NORM_CMD. Типы сообщений получателя NORM: NORM_NACK, NORM_ACK и NORM_REPORT.

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

Общая структура сообщения NORM

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
Общий заголовок сообщения
Заголовок типа сообщения
Дополнительные расширения заголовка
Полезная нагрузка

Заголовок общего сообщения NORM

Все сообщения NORM начинаются со следующего общего заголовка, определенного в RFC 5740, раздел 4.1, Общий заголовок и расширение сообщения NORM.

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
версия				тип				hdr_len								последовательность
source_id

версия (4 бита)

Номер версии протокола.

тип (4 бита)

Тип сообщения NORM (т. е. 1 = NORM_INFO, 2 = NORM_DATA, 3 = NORM_CMD, 4 = NORM_NACK, 5 = NORM_ACK, 6 = NORM_REPORT).

hdr_len (8 бит)

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

последовательность (16 бит)

Преследует две цели (в зависимости от типа сообщения):

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

source_id (32 бита)

Уникальный идентификатор узла, отправившего сообщение, в контексте данного сеанса NORM.

NORM_DATA Тип сообщения

Сообщение NORM_DATA, определенное в разделе 4.2.1 RFC 5740, является наиболее распространенным типом сообщения, передаваемым отправителями NORM. Сообщения NORM_DATA содержат сегментированные данные для типов NORM_OBJECT_DATA, NORM_OBJECT_FILE и NORM_OBJECT_STREAM.

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
версия				тип				hdr_len								последовательность
source_id
идентификатор_экземпляра																черт возьми								откат				размер
флаги								fec_id								object_transport_id
Fed_payload_id
header_extensions (если применимо)
payload_length (см. примечание 1)																payload_msg_start (см. примечание 1)
payload_offset (см. примечание 1)
payload_data

идентификатор_экземпляра (16 бит)

Уникальный идентификатор текущего экземпляра участия в сессии NORM.

гртт (8 бит)

Текущая оценка отправителем времени прохождения группы туда и обратно.

откат (4 бита)

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

gразмер (4 бита)

Текущая оценка размера группы отправителем.

флаги (32 бита)

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

fec_id

Идентификатор кодировки FEC. Это описано в документе FEC Building Block [RFC5052].

object_transport_id

Значение, присвоенное отправителем передаваемым объектам NORM, которое получатели используют для передач и запросов на восстановление. Оно увеличивается монотонно и постепенно.

fec_payload_id

Идентификатор прикрепленного содержимого полезных данных NORM_DATA.

Примечание 1

payload_length, payload_msg и payload_offset относятся только к содержимому NORM_OBJECT_STREAM.

Тип сообщения NORM_INFO

Сообщения NORM_INFO, определенные в разделе 4.2.2 RFC 5740, позволяют дополнительные внеполосные данные вместе с объектами содержимого данных. отправлять Это позволяет получателям определять характер соответствующего передаваемого контента, что, в свою очередь, позволяет на уровне приложения контролировать участие узла-получателя в сеансе.

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

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
версия				тип				hdr_len								последовательность
source_id
идентификатор_экземпляра																черт возьми								откат				размер
флаги								fec_id								object_transport_id
header_extensions (если применимо)
payload_data ...

идентификатор_экземпляра (16 бит)

Уникальный идентификатор текущего экземпляра участия в сессии NORM.

гртт (8 бит)

Текущая оценка отправителем времени прохождения группы туда и обратно.

откат (4 бита)

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

gразмер (4 бита)

Текущая оценка размера группы отправителем.

флаги (32 бита)

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

fec_id

Идентификатор кодировки FEC. Это описано в документе FEC Building Block [RFC5052].

object_transport_id

Значение, присвоенное отправителем передаваемым объектам NORM, которое получатели используют для передач и запросов на восстановление. Оно увеличивается монотонно и постепенно.

Тип сообщения NORM_CMD

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

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
версия				тип				hdr_len								последовательность
source_id
идентификатор_экземпляра																черт возьми								задняя часть				размер
флаги								fec_id								object_transport_id
подтип								NORM_CMD Содержимое
NORM_CMD Содержимое ...

идентификатор_экземпляра (16 бит)

Уникальный идентификатор текущего экземпляра участия в сессии NORM.

гртт (8 бит)

Текущая оценка отправителем времени прохождения группы туда и обратно.

откат (4 бита)

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

gразмер (4 бита)

Текущая оценка размера группы отправителем.

флаги (32 бита)

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

fec_id

Идентификатор кодировки FEC. Это описано в документе FEC Building Block [RFC5052].

object_transport_id

Значение, присвоенное отправителем передаваемым объектам NormObject, которое получатели используют для передач и запросов на восстановление. Оно увеличивается монотонно и постепенно.

под_тип (8 бит)

Указывает тип следующей команды.

NORM_CMD контент

• FLUSH: указывает на временное окончание передачи отправителя. Также может дополнительно использоваться для получения положительного подтверждения надежного приема от подмножества получателей.
• EOT: указывает на окончательное завершение передачи.
• SQUELCH: указывает текущее окно восстановления отправителя в ответ на NACK, выходящие за пределы диапазона.
• CC: используется для измерения GRTT и сбора обратной связи по управлению перегрузкой.
• REPAIR_ADV: объявляет совокупное состояние восстановления/обратной связи отправителя для подавления одноадресной обратной связи от получателей.
• ACK_REQ: запрашивает определенное приложением положительное подтверждение из списка получателей (НЕОБЯЗАТЕЛЬНО).
• ПРИЛОЖЕНИЕ: используется для целей, определяемых приложением, когда необходимо временно вытеснить или дополнить передачу данных (ОПЦИОНАЛЬНО).

Тип сообщения NORM_NACK

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

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
версия				тип				hdr_len								последовательность
source_id
server_id
идентификатор_экземпляра																сдержанный
grtt_response_sec
grtt_response_usec
header_extensions (если применимо)
nack_payload ...

server_id (32 бита)

Отправитель NORM, которому предназначено сообщение NORM_NACK.

идентификатор_экземпляра (16 бит)

Уникальный идентификатор текущего экземпляра участия в сессии NORM.

зарезервировано (16 бит)

Для потенциального будущего использования NORM

grtt_response_sec (32 бита)

Скорректированная версия временной метки самого последнего полученного сообщения NORM_CMD(CC) для указанного отправителя NORM.

grtt_response_usec (32 бита)

Скорректированная версия временной метки самого последнего полученного сообщения NORM_CMD(CC) для указанного отправителя NORM.

NACK_полезная нагрузка

Необходимость ремонта получателя по отношению к отправителю NORM, указанному в поле «server_id».

Тип сообщения NORM_ACK

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

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
версия				тип				hdr_len								последовательность
source_id
server_id
идентификатор_экземпляра																ack_type								ack_id
grtt_response_sec
grtt_response_usec
header_extensions (если применимо)
ack_payload (если применимо)

server_id (32 бита)

Отправитель NORM, которому предназначено сообщение NORM_ACK.

идентификатор_экземпляра (16 бит)

Уникальный идентификатор текущего экземпляра участия в сессии NORM.

ack_type (8 бит)

Характер сообщения NORM_ACK. Это напрямую соответствует полю «ack_type» сообщения NORM_CMD(ACK_REQ), к которому применяется это подтверждение.

ack_id (8 бит)

Порядковый номер, позволяющий отправителю проверить полученное сообщение NORM_ACK, действительно относится к текущему запросу подтверждения. Поле «ack_id» не используется в случае типов подтверждения NORM_ACK(CC) и NORM_ACK(FLUSH).

grtt_response_sec (32 бита)

Скорректированная версия временной метки самого последнего полученного сообщения NORM_CMD(CC) для указанного отправителя NORM.

grtt_response_usec (32 бита)

Скорректированная версия временной метки самого последнего полученного сообщения NORM_CMD(CC) для указанного отправителя NORM.

ack_payload (если применимо)

Формат «ack_payload» является функцией «ack_type».

NORM_REPORT Тип сообщения

Сообщение NORM_REPORT, обсуждаемое в разделе 4.4.1 RFC 5740, является необязательным сообщением. Формат на данный момент не определен.

Расширения заголовка NORM

Необязательные расширения заголовка, определенные в разделе 4.1 RFC 5740, следуют за общим заголовком и заголовком, специфичным для сообщения, и предшествуют полезным данным (если таковые имеются). Расширения заголовков обычно содержат информацию, связанную с базовым FEC, операциями по контролю перегрузки и другую информацию по управлению сеансом. Существует два типа расширений заголовков: переменной длины и фиксированной длины.

Расширение заголовка переменной длины

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
это ≤ 127								весь								Содержание расширения заголовка
Содержание расширения заголовка ...

это (8 бит)

Тип расширения заголовка. Для расширений заголовков переменной длины — значение от 0 до 127 (включительно).

хель (8 бит)

Длина расширения заголовка. Указывает длину всего расширения заголовка.

содержимое расширения заголовка

Варьируется в зависимости от цели.

Расширение заголовка фиксированной длины

0								1								2								3
0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
оно ≥ 128								сдержанный								Содержание расширения заголовка

это (8 бит)

Тип расширения заголовка. Для расширений заголовков фиксированной длины — значение от 128 до 255 (включительно).

зарезервировано (8 бит)

Зарезервировано для будущего использования.

содержимое расширения заголовка (16 бит)

Варьируется в зависимости от цели.

Протокол работы

Общие операции

Следующая общая работа протокола NORM описана в RFC 5740, раздел 5, Подробное описание работы протокола.

1. После установления сеанса NORM отправитель сегментирует объект NORM в последовательность с порядковым номером. Эти сегменты передаются как сообщения NORM_DATA. Помимо содержимого данных, сообщения NORM_DATA помечаются уникальными идентификаторами и идентификаторами FEC. Отправитель также может отправлять внеполосные сообщения NORM_INFO, связанные с контентом NORM_DATA, которые позволяют получателям определять природу соответствующего контента, что, в свою очередь, позволяет на уровне приложения управлять участием узла-получателя в сеансе.

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

2. Когда получатели обнаруживают недостающее содержимое от отправителя, они могут попытаться восстановить его с помощью механизмов FEC. За исключением успешного ремонта, получатели отправят отправителю сообщения NORM_NACK. Используя порядковую информацию о последовательности, получатели определяют недостающее содержимое.

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

4. Когда отправитель достигает конца набора запросов на восстановление, он передает сообщение NORM_CMD(FLUSH), указывающее на временное завершение передачи.

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

Управление сеансом

Хотя NORM не является протоколом, ориентированным на соединение , как TCP, он имеет характеристики как ориентированного на соединение, так и без него.

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

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

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

Контроль перегрузок

NORM использует схему управления перегрузкой, дружественную к TCP, которая позволяет справедливо распределять доступную полосу пропускания с TCP и другими транспортными протоколами. В частности, схема управления перегрузкой NORM использует процедуру управления скоростью и представляет собой адаптацию подхода спецификации протокола TCP-Friendly Multicast Congestion Control [TFMCC], описанного в RFC4654. Было продемонстрировано, что этот подход хорошо работает с потоками данных TCP и многоадресной рассылки.

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

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

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

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

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

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

2. Неявный водяной знак. Этот параметр основан на отсутствии запросов на восстановление отрицательного подтверждения (NACK) от набора получателей. Отправитель использует NORM_CMD(FLUSH) для оповещения получателей о NACK о любом необходимом ремонте через указанный водяной знак. Затем отправитель ждет, пока очистка полностью завершится. Если активности NACK не было, отправитель считает, что «водяной знак» завершен, и может продолжить отправку новых данных.

3. Мягкое управление потоком на основе таймера. Эта опция сохраняет передаваемые данные и ограничивает продвижение окна восстановления на основе группового времени приема-передачи (GRTT) и активности NACK. Устанавливается минимальный адаптируемый лимит времени, по истечении которого отправитель может продолжить отправку новых данных. Этот лимит времени основан на оценке отправителя GRTT и отсутствии активности NACK.

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

Надежность

NORM обеспечивает надежную транспортировку за счет использования двух схем кодирования с прямым исправлением ошибок : систематических кодов и несистематических кодов. Они обсуждаются в RFC 5740, раздел 2, Определение архитектуры:

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

При использовании несистематических кодов отправитель кодирует контент с помощью FEC перед передачей.

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

Масштабируемость и управление NACK

Многоадресная передача, ориентированная на NACK, подвержена срывам NACK. Если большое количество получателей NACK одновременно, это может привести к перегрузке отправителя, а также всей сети. NORM использует механизм подавления NACK, описанный в RFC 5740, раздел 5.3, Процедура NACK приемника, для предотвращения взрыва NACK.

Когда получатель обнаруживает отсутствие данных в передачах NORM отправителя, он инициирует процедуру NACK:

• Существует предположение, что один или несколько других получателей пропустили те же данные и что NACK, возможно, уже был отправлен отправителю.
• Приемник входит в период задержки на основе алгоритма случайной задержки. Продолжительность этого тайм-аута определяется алгоритмом «RandomBackoff», описанным в многоадресном блоке NACK Building Block [RFC5401], и основана на информации, которую отправитель передавал в полях «grtt», «backoff» и «gsize». передаваемых им сообщений.
• В течение периода задержки получатель продолжает получать и оценивать сообщения о восстановлении от отправителя и подавляет свой собственный NACK.
• Если в конце периода задержки получатель не получил достаточной информации о ремонте, он инициирует свой NACK.
• Если сеанс NORM происходит в среде многоадресной маршрутизации, NACK передается отправителю, а также всем другим узлам в сети.
• Если сеанс NORM не происходит в среде многоадресной маршрутизации, NACK передается отправителю, и отправитель немедленно повторно отправляет его всем остальным узлам сети.

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

Эталонная реализация

Лаборатория военно-морских исследований США поддерживает в свободном доступе эталонную реализацию протокола NORM на GitHub . Сюда входит исходный код, руководство разработчика и руководство пользователя.

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

• RFC 1112 — Расширения хоста для многоадресной IP-рассылки, август 1989 г.
• RFC 2357 — Критерии IETF для оценки надежных протоколов многоадресной передачи и приложений, июнь 1998 г.
• RFC 2974 — Протокол объявления сессии, октябрь 2000 г.
• RFC 3048 — Надежные строительные блоки многоадресной передачи для массовой передачи данных «один ко многим», январь 2001 г.
• RFC 3269 — Рекомендации автора по строительным блокам надежной многоадресной передачи (RMT) и документам по созданию экземпляров протоколов, апрель 2002 г.
• RFC 3453 — Использование прямой коррекции ошибок (FEC) в надежной многоадресной рассылке, декабрь 2002 г.
• RFC 3547 — Групповая область интерпретации, июль 2003 г.
• RFC 3550 — RTP: транспортный протокол для приложений реального времени, июль 2003 г.
• RFC 3830 — MIKEY: Мультимедийный Интернет-ключ, август 2004 г.
• RFC 3940 - Протокол надежной многоадресной рассылки (NORM), ориентированный на отрицательное подтверждение (NACK), ноябрь 2004 г.
• RFC 4301 — Архитектура безопасности Интернет-протокола, декабрь 2005 г.
• RFC 4303 — Полезная нагрузка безопасности, инкапсулирующая IP (ESP), декабрь 2005 г.
• RFC 4535 — GSAKMP: протокол управления ключами групповой безопасной ассоциации, июнь 2006 г.
• RFC 4566 — SDP: протокол описания сеанса, июль 2006 г.
• RFC 4607 — Многоадресная рассылка с учетом источника для IP, август 2006 г.
• RFC 4654 — TCP-Friendly Multicast Congestion Control (TFMCC): спецификация протокола, август 2006 г.
• RFC 5052 — Строительный блок прямого исправления ошибок (FEC), август 2007 г.
• RFC 5401 — Строительные блоки многоадресного отрицательного подтверждения (NACK), ноябрь 2008 г.
• RFC 5445 — Базовые схемы прямого исправления ошибок (FEC), март 2009 г.
• RFC 5740 — Транспортный протокол надежной многоадресной рассылки, ориентированный на NACK (NORM), ноябрь 2009 г.

См. также

• Протокол передачи управления потоком

Дальнейшее чтение

• Д. Кларк, Д. Тенненхаус, «Архитектурные соображения для нового поколения протоколов». Учеб. ACM SIGCOMM, сентябрь 1990 г.
• С. Флойд и В. Джейкобсон, «Случайные шлюзы раннего обнаружения для предотвращения перегрузок», Транзакции IEEE/ACM в сети, V.1 N.4, август 1993 г.
• С. Пингали, Д. Таусли, Дж. Куросе. «Сравнение надежных протоколов многоадресной рассылки, инициируемых отправителем и получателем». Учеб. ИНФОКОМ, Сан-Франциско, Калифорния, октябрь 1993 г.
• С. Флойд, В. Джейкобсон, С. Макканн, К. Лю и Л. Чжан. «Надежная структура многоадресной рассылки для облегченных сеансов и формирования кадров на уровне приложения», Proc. ACMSIGCOMM, август 1995 г.
• Дж. Маккер, «Надежная многоадресная передача и интегрированное прямое исправление ошибок на основе стирания», Proc. IEEE MILCOM 97, октябрь 1997 г.
• А. Манкин, А. Романов, С. Брэднер, В. Паксон, «Критерии IETF для оценки надежных протоколов многоадресной передачи и приложений», RFC 2357, июнь 1998 г.
• Д. ДеЛюсия, К. Обрачка , «Эффективность управления перегрузкой надежного протокола многоадресной рассылки», Proc. IEEE ICNP 98, август 1998 г.
• Д. Госсинк, Дж. Маккер, «Надежная многоадресная рассылка и интегрированная повторная передача по четности с оценкой канала», IEEE GLOBECOM 98, октябрь 1998 г.
• Б. Веттон и Дж. Конлан, «Схема управления перегрузкой на основе скорости для надежной многоадресной рассылки», технический отчет, GlobalCast Communication, октябрь 1998 г.

Внешние ссылки

• НОРМ Транспортные примечания
• Использование протокола Nack Oriented Reliable Multicast (NORM) для передачи телеметрии космического корабля в наземные сети на nasa.gov