Надежное сжатие заголовка

Надежное сжатие заголовков ( ROHC ) — это стандартизированный метод сжатия IP , UDP , UDP-Lite , RTP и TCP заголовков интернет- пакетов.

Необходимость сжатия заголовков

В потоковых приложениях служебные данные IP, UDP и RTP составляют 40 байт для IPv4 или 60 байт для IPv6 . Для VoIP это соответствует примерно 60% от общего объема отправленных данных. Такие большие накладные расходы могут быть приемлемыми в локальных проводных каналах связи, где пропускная способность часто не является проблемой, но они чрезмерны для глобальных сетей и беспроводных систем, где пропускная способность ограничена. ^[1]

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

Схема сжатия ROHC отличается от других схем сжатия, таких как IETF. RFC 1144 and RFC 2508 , поскольку он хорошо работает по каналам с высокой скоростью потери пакетов, например по беспроводным каналам.

Основные принципы сжатия ROHC

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

один сетевой пакет (например, длина полезной нагрузки в заголовках IP и UDP)
несколько сетевых пакетов, принадлежащих одному потоку (например, IP-адреса)

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

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

Несжатый
только IP
UDP/IP
UDP-Lite/IP
ЭСП/ИП
RTP/UDP/IP
RTP/UDP-Lite/IP
TCP/IP

Режимы работы

Согласно RFC 3095, схема ROHC имеет три режима работы:

Однонаправленный режим (U-режим)
Двунаправленный оптимистичный режим (O-режим)
Двунаправленный надежный режим (R-режим)

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

Однонаправленный режим (U-режим)

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

Двунаправленный оптимистический режим (O-режим)

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

Двунаправленный надежный режим (R-режим)

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

Состояния компрессора/декомпрессора

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

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

Состояние компрессора

Конечный автомат компрессора определяет следующие три состояния:

Состояние инициализации и обновления (IR)
Состояние Первого Ордена (FO)
Состояние второго порядка (SO)

Работа в различных состояниях компрессора

В состоянии инициализации и обновления (IR) компрессор только что был создан или сброшен, и отправляются полные заголовки пакетов. В состоянии первого порядка (FO) компрессор обнаружил и сохранил статические поля (такие как IP-адреса и номера портов) на обеих сторонах соединения. Компрессор также отправляет динамические различия в полях пакетов в состоянии FO. Таким образом, состояние ФО по сути представляет собой статическое и псевдодинамическое сжатие. В состоянии второго порядка (SO) компрессор подавляет все динамические поля, такие как порядковые номера RTP, и отправляет только логический порядковый номер и частичную контрольную сумму, чтобы заставить другую сторону прогнозировать создание и проверку заголовков следующего ожидаемого пакета. В общем, состояние FO сжимает все статические поля и большинство динамических полей. Состояние SO прогнозирует сжатие всех динамических полей с использованием порядкового номера и контрольной суммы.

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

Переходы между вышеуказанными состояниями происходят, когда компрессор:

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

Заголовки ROHC второго порядка – 1-байтовые заголовки

Типичная реализация ROHC будет направлена на перевод терминала в состояние второго порядка, где 1-байтовый заголовок ROHC может быть заменен на 40-байтовый заголовок IPv4/UDP/RTP или 60-байтовый заголовок IPv6/UDP/RTP (т. е. VoIP). заголовок. В этом состоянии 8-битный заголовок ROHC содержит три поля:

1-битный флаг типа пакета (установлен в «1» только для более длинных заголовков ROHC)
4-битный порядковый номер (с диапазоном −1...+14 пакетов из базового кадра)
3-битный CRC

Состояния декомпрессора

Конечный автомат декомпрессора определяет следующие три состояния:

Нет состояния контекста
Статическое состояние контекста
Полное состояние контекста

Переходы между вышеуказанными состояниями происходят, когда декомпрессор:

успешно распаковывает пакет
не удается распаковать несколько пакетов

Надежность

Размер поля порядкового номера (SN) определяет количество пакетов, которые ROHC может потерять, прежде чем компрессор необходимо будет перезапустить для продолжения работы. Алгоритм W-LSB используется для надежного сжатия SN. Размер порядкового номера в 1- и 2-байтовых пакетах ROHC составляет либо 4 бита (смещение кадра -1/+14), либо 6 бит (смещение кадра -1/+62) соответственно, поэтому ROHC может допустить не более 62 потерянных битов. кадры с заголовком 1-2 байта.

Дополнительные профили сжатия

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

The RFC 3843 определяет профиль сжатия для IP-заголовков или IP-туннелей.
The RFC 4019 определяет профиль сжатия для заголовков UDP-Lite/IP и RTP/UDP-Lite/IP.
The RFC 6846 определяет профиль сжатия заголовков TCP/IP.

Новые RFC ROHC

Опубликовано два новых RFC. RFC 4995 and RFC 5225 , чтобы устранить путаницу, с которой некоторые столкнулись при попытке интерпретировать и реализовать ROHC. Первый документ определяет структуру ROHC, а второй определяет новые версии установленных профилей ROHC.

См. также

Ссылки

^ Майкл Дош и Стив Черч. «VoIP в студии вещания» . Аксиа Аудио. Архивировано из оригинала 7 октября 2011 г. Проверено 21 июня 2011 г.

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

Официальный устав рабочей группы ROHC IETF
RFC 3095 — «Структура ROHC и четыре профиля: RTP, UDP, ESP и несжатый»
RFC 3759 — «Терминология ROHC и примеры сопоставления каналов»
RFC 4815 - "Corrections and Clarifications to РФК 3095 "
RFC 4995 — «Структура сжатия заголовков RObust (ROHC)» (устарела из-за RFC 5795)
RFC 4996 - «Сжатие заголовка RObust (ROHC): профиль для TCP/IP (ROHC-TCP)» (устарело из-за RFC 6846)
RFC 4997 — «Формальное обозначение ROHC».
RFC 5225 — «Сжатие заголовка RObust, версия 2 (ROHCv2): профили для RTP, UDP, IP, ESP и UDP-Lite». Вторая версия профилей содержится в RFC 3095, RFC 3843 и RFC 4019. Она заменяет их определения, но не делает их устаревшими.
RFC 5795 - «Структура сжатия заголовков RObust (ROHC)» (устарела RFC 4995)
RFC 6846 - «Сжатие заголовка RObust (ROHC): профиль для TCP/IP (ROHC-TCP)» (устарел RFC 4996)
Бесплатная реализация ROHC на sourceforge.net.
Бесплатная и эффективная библиотека, реализующая стандарт ROHC.

[1] Майкл Дош и Стив Черч. «VoIP в студии вещания» . Аксиа Аудио. Архивировано из оригинала 7 октября 2011 г. Проверено 21 июня 2011 г.

[1]