ROHC
ROHC (англ. Robust Header Compression — Надёжное (Помехоустойчивое) Сжатие Заголовков) стандартизированный метод сжатия IP, UDP, UDP Lite, RTP и TCP заголовков Интернет пакетов.
Необходимость сжатия заголовков
Размер заголовков в IP, UDP, и RTP пакетах составляет 40 байт для IPv4, или 60 байт для IPv6, что, например, для VoIP занимает порядка 60 % пересылаемых данных. Столь большие расходы вполне уместны для локальных и высокоскоростных сетей, но чрезмерны для WAN и беспроводных сетей, где трафик и скорость сильно ограничены [1].
ROHC сжимает эти 40 или 60 байт до 1-3 помещая компрессор, сжимающий большие заголовки в несколько байт, на одном конце соединения и декомпрессор, проделывающий обратную операцию, на другом.
Схема сжатия ROHC отличается от других схем, вроде IETF RFC 1144 и RFC 2508, тем, что не испытывает проблем при работе с сетями с большими коэффициентами потерь данных.
Основные принципы
Протокол ROHC отлично справляется с избыточностью информации заголовков в:
- одном пакете (полезная нагрузка IP и UDP заголовков)
- множестве пакетов, принадлежащих одному потоку данных (например по одному IP адресу)
Полная информация передаётся только в первом из пакетов, остальные содержат лишь переменную информацию, вроде идентификаторов или номеров последовательности.
Для большей производительности пакеты классифицируются по потокам, что позволяет избежать межпакетной избыточности. Алгоритм подобной классификации не специализирован самим протоколом ROHC, а оставлен для свободной реализации поставщикам оборудования. После неё пакеты сжимаются наиболее подходящим профилем, который задаёт способы сжатия сетевых заголовков. Доступны несколько профилей сжатия: Несжатый (Uncompressed), только IP (IP-only), IP/UDP, IP/UDP-Lite, IP/ESP, IP/UDP/RTP, IP/UDP-Lite/RTP и IP/TCP.
Режимы
В соответствии с RFC 3095 у схемы ROHC есть три режима работы:
- Однонаправленный (U-mode),
- Двунаправленный оптимистичный (O-mode),
- Двунаправленный надёжный (R-mode).
Как компрессор, так и декомпрессор начинают свою работу в U-mode. После чего они могут переключиться на O-mode, когда станет доступно обратное соединение и декомпрессор подтвердит переключение на O-mode. Переключение на R-mode происходит тем же образом.
Однонаправленный (U-Mode)
В однонаправленном режиме пакеты посылаются только в направлении от компрессора к декомпрессору. Это, к тому же, позволяет использовать ROHC в соединениях, где обратная связь между компрессором и декомпрессором невозможна или нежелательна. Во избежание потенциальных ошибок сжатия компрессор периодически отсылает обновления контекста потока данных декомпрессору.
Двунаправленный оптимистичный (O-Mode)
Двунаправленный оптимистичный режим схож с предыдущим, но обладает каналом обратной связи, который используется для запросов декомпрессором восстановления ошибочных данных и (опционально) подтверждения значимых обновлений контекста потока. Данный режим нацелен на максимальную эффективность использования сжатия и применяется при редком использовании канала обратной связи.
Двунаправленный надёжный (R-Mode)
Двунаправленный надёжный режим во многом отличается от двух предыдущих. Главная разница — куда более интенсивное использование канала обратной связи и строгая логика работы компрессора и декомпрессора, предотвращающая потери данных и рассинхронизацию контекста потока передачи.
Состояния компрессора/декомпрессора
Вне зависимости от текущего режима, как компрессор, так и декомпрессор работают в одном из трёх состояний, которые по сути являются конечными автоматами. Каждый входящий пакет может сменить текущее состояние, которое описывает поведение и уровень сжатия данных.
Алгоритм ROHC напоминает сжатие видео, где основной фрейм и несколько фреймов с различиями отсылаются для представления потока IP пакетов. У такого метода есть серьёзные преимущества, позволяющие игнорировать большие потери даже при самом сильном сжатии, до тех пор пока не потерян основной (базовый) фрейм.
Состояния компрессора
Для компрессора определены следующие три состояния:
- Инициализация и обновление (IR),
- Первый порядок (FO),
- Второй порядок (SO).
Операции с различными состояниями компрессора
В состоянии IR компрессор находится сразу после того как был создан или перезапущен, и при этом отсылает полные заголовки пакетов.
В состояние FO компрессор переходит, после того, как обнаружил и сохранил все данные статичных полей пакета (например IP адрес и номер порта) на обоих концах соединения. Декомпрессору в этом состоянии также отсылаются различные изменения динамических полей. Как видно, FO использует статичное и псевдо-динамическое сжатие.
В последнем состоянии компрессор подавляет все динамические данные, вроде номеров RTP последовательности, и отсылает только номер логической последовательности и частичные контрольные суммы, позволяя противоположной стороне предугадывая генерировать и проверять заголовок следующего ожидаемого пакета. В целом, если в FO состоянии сжимаются все статические и многие динамические поля заголовков, то в SO сжимаются все динамические поля с использованием нумерации последовательности пакетов и контрольных сумм.
Смена состояния компрессора
Переключение между вышеописанными состояниями происходит, когда компрессор:
- сжимает пакет, содержащий слишком много изменений относительно предыдущих,
- получает положительный/отрицательный ответ от декомпрессора,
- периодически обновляет контекст.
1-байтовые ROHC-заголовки
Обычная реализация ROHC ставит целью перевести терминал в состояние SO, когда 1-байтовый ROHC заголовок может быть раскрыт в соответствующий 40-байтовый IPv4/UDP/RTP или 60-байтовый IPv6/UDP/RTP (то есть VoIP) заголовок. В данном состоянии этот 1 байт (8 бит) включает в себя:
- 1 бит, характеризующий тип текущего пакета (выставляется '1' для более длинных пакетов),
- 4 бита, для номера последовательности (из диапазона −1..+14 пакетов относительно базового),
- 3 бита CRC.
Состояния декомпрессора
Для декомпрессора определены другие три состояния:
- Без контекста,
- Статический контекст,
- Полный контекст.
Переключение между ними происходит, когда декомпрессор:
- успешно раскрывает пакет,
- неудачно раскрывает пакет.
Надёжность
Диапазон номеров последовательности характеризует количество пакетов, которое может быть потеряно, после чего компрессор будет вынужден обновить состояние. Ширина диапазона в 1 и 2 байтовых ROHC пакетах составляет 4 (-1..+14 смещение относительно базового) и 6 (-1..+62) битов соответственно. Таким образом, максимальное количество утерянных пакетов, которое ROHC игнорирует, составляет 62 для 1-2 байтовых заголовков.
Дополнительные профили сжатия
RFC 3095 определяет шаблон механизма сжатия, который может быть расширен для использования других профилей, в зависимости от специфики заголовков определённого протокола, так
- RFC 3843 задаёт профиль сжатия для IP заголовков или IP туннелей,
- RFC 4019 для IP/UDP-Lite и IP/UDP-Lite/RTP заголовков,
- RFC 6846 для IP/TCP заголовков.
Примечания
- ↑ Michael Dosch and Steve Church. VoIP In The Broadcast Studio (недоступная ссылка). Axia Audio. Дата обращения: 21 июня 2011. Архивировано 7 октября 2011 года.
Ссылки
- Официальный раздел рабочей группы ROHC IETF Архивная копия от 11 ноября 2014 на Wayback Machine
- RFC 3095 — «ROHC Framework and four profiles: RTP, UDP, ESP, and uncompressed»
- RFC 3759 — «ROHC Terminology and Channel Mapping Examples»
- RFC 4815 — «Corrections and Clarifications to RFC 3095»
- RFC 4995 — «The RObust Header Compression (ROHC) Framework» (obsoleted by RFC 5795)
- RFC 4996 — «RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)»
- RFC 4997 — «Formal Notation for ROHC»
- RFC 5225 — «RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite». Second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019. It supersedes their definition, but does not obsolete them.
- RFC 5795 — «The RObust Header Compression (ROHC) Framework» (obsoletes RFC 4995)
- RFC 6846 — «RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)»
- Свободная реализация ROHC на sourceforge.net Архивная копия от 28 марта 2015 на Wayback Machine
- Свободная и эффективная библиотека, реализующая стандарт ROHC Архивная копия от 18 декабря 2014 на Wayback Machine