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 заголовков.

Примечания[править | править код]

  1. Michael Dosch and Steve Church. VoIP In The Broadcast Studio. Axia Audio. Дата обращения: 21 июня 2011. Архивировано из оригинала 7 октября 2011 года.

Ссылки[править | править код]