N/RFCNET
← Карточка документаEnglish original ↗

RFC 5795 · март 2010

Архитектура устойчивого сжатия заголовков (ROHC)

Авторы: K. Sandlund, G. Pelletier, L-E. Jonsson. Категория: стандарт. Март 2010. Заменяет RFC 4995.

Аннотация

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

Архитектура ROHC вместе с набором профилей сжатия первоначально была определена в RFC 3095. Чтобы улучшить и упростить спецификации ROHC, этот документ отдельно определяет архитектуру ROHC и профиль без сжатия. При этом определение архитектуры не изменяет и не обновляет определение, приведённое в RFC 3095.

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

Статус документа

Этот документ относится к стандартам Интернета.

Документ подготовлен Инженерной группой Интернета (IETF) и отражает консенсус её сообщества. Он прошёл публичное рассмотрение и одобрен к публикации Руководящей группой по инженерным вопросам Интернета (IESG). Дополнительные сведения о стандартах Интернета приведены в разделе 2 RFC 5741.

Сведения о текущем статусе документа, исправлениях и способах обратной связи можно получить по адресу http://www.rfc-editor.org/info/rfc5795.

Уведомление об авторских правах

Copyright (c) 2010 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На документ распространяются BCP 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действовавшие на дату публикации. Внимательно ознакомьтесь с ними: они описывают ваши права и ограничения. Компоненты программного кода, извлечённые из документа, должны включать текст упрощённой лицензии BSD, как указано в разделе 4.e Правовых положений IETF Trust, и предоставляются без гарантий, как описано в этой лицензии.

Документ может содержать материалы из документов или вкладов IETF, опубликованных или предоставленных в открытый доступ до 10 ноября 2008 года. Обладатели авторских прав на некоторые из этих материалов могли не предоставить IETF Trust право разрешать их изменение вне процесса стандартизации IETF. Без соответствующей лицензии правообладателей документ нельзя изменять или создавать производные произведения вне этого процесса, за исключением форматирования для публикации в качестве RFC или перевода на другие языки.

1. Введение

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

Для каналов, где накладные расходы заголовков IP создают проблему, общий размер заголовка может быть значительным. Приложения, передающие данные внутри RTP [RFC3550], помимо кадров канального уровня, используют заголовок IPv4 [RFC0791] размером 20 октетов, заголовок UDP [RFC0768] размером 8 октетов и заголовок RTP размером 12 октетов, всего 40 октетов. В IPv6 [RFC2460] заголовок IPv6 занимает 40 октетов, а общая длина составляет 60 октетов. Приложения, использующие TCP [RFC0793], имеют транспортный заголовок размером 20 октетов: в сумме 40 октетов для IPv4 и 60 для IPv6.

Относительный выигрыш для конкретных потоков или приложений зависит от размера полезной нагрузки каждого пакета. Для таких приложений, как передача голоса по IP, где полезная нагрузка с закодированной речью может занимать всего 15–20 октетов, выигрыш будет весьма существенным. Аналогично относительный выигрыш для потоков TCP с большой полезной нагрузкой, например при передаче файлов, будет меньше, чем для потоков с небольшой нагрузкой, например сигнализации приложений при установлении сеанса.

По мере внедрения всё большего числа беспроводных технологий для передачи IP-трафика необходимо учитывать их специфические характеристики в алгоритмах сжатия заголовков. Показано, что прежние схемы, например [RFC2507] и [RFC2508], работают недостаточно хорошо на каналах, где значимы как потери, так и время кругового обхода, как это бывает, например, в беспроводных каналах и IP-туннелях.

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

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

RFC 3095 [RFC3095] определяет архитектуру ROHC вместе с первоначальным набором профилей сжатия. Чтобы улучшить и упростить спецификацию, части, посвящённые архитектуре и профилям, разделены на отдельные документы. Этот документ явно определяет архитектуру ROHC, но не изменяет и не обновляет её определение в RFC 3095; оба документа могут использоваться независимо. Это также означает, что реализации на основе любого из них совместимы и могут взаимодействовать друг с другом. При этом предполагается, что настоящая спецификация заменит RFC 3095 в качестве базовой спецификации для всех профилей, определяемых в будущем.

Этот документ исправляет одну проблему совместимости, ошибочно внесённую в RFC 4995. Исправление находится в разделе 5.2.4.1 и уточняет интерпретацию поля Size в обратной связи ROHC.

2. Терминология

Ключевые слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY и OPTIONAL в этом документе следует понимать согласно [RFC2119]. В переводе они передаются как ДОЛЖЕН, НЕ ДОЛЖЕН, ОБЯЗАТЕЛЬНО, СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, МОЖЕТ и НЕОБЯЗАТЕЛЬНО в соответствии с контекстом.

2.1. Сокращения

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

ACK — подтверждение.
CID — идентификатор контекста.
CO — формат сжатого пакета.
CRC — циклический избыточный код.
IR — инициализация и обновление.
IR-DYN — инициализация и обновление динамической части.
LSB — младший значащий бит.
MRRU — максимальный размер восстанавливаемой единицы приёма.
MSB — старший значащий бит.
MSN — главный порядковый номер.
NACK — отрицательное подтверждение.
ROHC — устойчивое сжатие заголовков.

2.2. Терминология ROHC

Контекст

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

Повреждение контекста

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

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

Механизмы восстановления контекста

Механизмы повторной синхронизации контекстов; это важная задача, поскольку повреждение контекста вызывает распространение потерь. Примеры — механизмы на основе NACK и периодическое обновление важных сведений контекста, обычно применяемое при однонаправленной работе. Существуют также механизмы уменьшения вероятности несогласованности, например повторение однотипной информации в нескольких пакетах и CRC для защиты информации, обновляющей контекст.

Проверка CRC-8

Проверка целостности полученного заголовка IR или IR-DYN на наличие битовых ошибок с помощью восьмибитного CRC, содержащегося в этом заголовке.

Проверка CRC

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

Распространение повреждений

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

Обнаружение ошибок

Обнаружение ошибок нижними уровнями. Если оно несовершенно, остаются остаточные ошибки.

Распространение ошибок

Распространение повреждений или распространение потерь.

Профиль ROHC

Протокол сжатия, определяющий способ сжатия конкретных сочетаний заголовков. Профиль ROHC может быть приспособлен к определённому набору характеристик канала, например к характеристикам потерь и перестановке пакетов между точками сжатия. Профили ROHC конкретизируют определённую в этом документе архитектуру сжатия заголовков; каждому профилю соответствует уникальный идентификатор [ROHC-ids]. При создании канала ROHC согласуется набор профилей, поддерживаемых обеими его конечными точками. При инициализации новых контекстов идентификатор профиля из согласованного набора связывает каждый контекст сжатия с конкретным профилем.

Канал связи

Физический путь передачи, представляющий один переход IP.

Распространение потерь

Потеря заголовков вследствие ошибок (потери или повреждения) предыдущих заголовков либо обратной связи.

Поток пакетов

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

Остаточная ошибка

Ошибка, возникшая при передаче и не обнаруженная механизмами проверки ошибок нижнего уровня.

Канал ROHC

Логический однонаправленный канал «точка — точка», передающий пакеты ROHC от одного компрессора одному декомпрессору и, при необходимости, информацию обратной связи ROHC от имени другой пары компрессора и декомпрессора, работающей по отдельному каналу ROHC в обратном направлении. См. также [RFC3759].

В документе также используется понятийная терминология RFC 3759 «Терминология ROHC и примеры отображения на каналы» [RFC3759].

3. Предыстория (информационный раздел)

Раздел знакомит с темой сжатия заголовков. Описываются основные идеи и история схем сжатия, мотивы разработки различных схем и их недостатки, что создаёт основу для архитектуры и профилей ROHC [RFC3095].

3.1. Основы сжатия заголовков

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

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

3.2. Краткая история сжатия заголовков

Первую схему сжатия заголовков, сжатый TCP (CTCP) [RFC1144], предложил Van Jacobson. CTCP, также часто называемый сжатием VJ, сокращает заголовок TCP/IP с 40 до 4 октетов. Для последовательно изменяющихся полей CTCP использует кодирование разностей. Компрессор CTCP обнаруживает повторные передачи на транспортном уровне и при их возникновении отправляет заголовок, обновляющий весь контекст. Этот механизм восстановления не требует явной сигнализации между компрессором и декомпрессором.

Общая схема сжатия заголовков IP [RFC2507] несколько улучшает CTCP. IPHC может сжимать произвольные заголовки IP, TCP и UDP. При сжатии заголовков иных протоколов, кроме TCP, IPHC не использует кодирование разностей и является устойчивой. Механизм восстановления CTCP дополнен отрицательными подтверждениями CONTEXT_STATE, ускоряющими восстановление. Таким образом, этот механизм ограничен временем кругового обхода канала. IPHC не сжимает заголовки RTP.

CRTP [RFC2508] — расширение IPHC для RTP. CRTP сжимает 40 октетов заголовков IPv4/UDP/RTP минимум до 2 октетов, когда контрольная сумма UDP не используется. Если она включена, минимальный заголовок CRTP занимает 4 октета.

На каналах с потерями и большим временем кругового обхода CRTP работает плохо [CRTP-eval]. Каждый потерянный в канале пакет приводит к неудаче восстановления нескольких последующих пакетов, поскольку контекст становится недействительным как минимум на время одного кругового обхода после потери. К сожалению, большие заголовки, отправляемые CRTP для обновления контекста, дополнительно расходуют пропускную способность.

CRTP использует локальный механизм восстановления TWICE, введённый в IPHC. Его название связано с наблюдением: при регулярном потоке сжатых пакетов, если один пакет между точками сжатия потерян, правильно предположить, что обновление из текущего пакета нужно применить дважды. Хотя TWICE значительно улучшает работу CRTP, исследование [CRTP-eval] показало, что даже с TWICE CRTP удваивал число потерянных пакетов.

Усовершенствованный вариант CRTP, называемый eCRTP [RFC3545], предназначен для повышения устойчивости к перестановке и потере пакетов при почти неизменном протоколе. В результате eCRTP предоставляет лучшие средства достижения определённой устойчивости, но ценой дополнительных накладных расходов, что снижает эффективность сжатия по сравнению с CRTP.

4. Обзор ROHC (информационный раздел)

4.1. Общие принципы

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

Первый шаг — выделить пакеты и сгруппировать их в разные «потоки» так, чтобы максимизировать избыточность между пакетами и улучшить степень сжатия. Группировка обычно основана на IP-адресах отправителя и получателя, типе транспортного протокола (например, UDP или TCP), номерах процессов (портов) и, возможно, дополнительных уникальных идентификаторах приложения, таких как источник синхронизации SSRC в RTP [RFC3550]. Компрессор и декомпрессор создают контекст для потока и обозначают его идентификатором контекста CID, включённым в каждый сжатый заголовок.

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

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

STATIC — предполагается, что поля постоянны в течение жизни потока пакетов, поэтому значение каждого передаётся только в начале.

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

STATIC-KNOWN — предполагается, что поля имеют общеизвестные значения, поэтому передавать их не требуется.

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

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

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

4.2. Эффективность сжатия, устойчивость и прозрачность

Работу протокола сжатия заголовков можно описать тремя параметрами: эффективностью сжатия, устойчивостью и прозрачностью сжатия.

Эффективность сжатия определяется тем, насколько уменьшается средний размер заголовка при применении протокола.

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

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

4.3. Разработка протокола ROHC

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

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

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

Документ «Устойчивое сжатие заголовков (ROHC): архитектура и четыре профиля: RTP, UDP, ESP и без сжатия» [RFC3095] был опубликован в 2001 году как первый результат работы группы ROHC. ROHC — общая расширяемая архитектура сжатия заголовков, поверх которой можно определять профили для заголовков различных протоколов. RFC 3095 ввёл ряд новых методов сжатия и успешно выполнил предъявленные требования, описанные в [RFC3096].

Испытания совместимости RFC 3095 подтвердили способность ROHC выполнять поставленные задачи, однако отзывы разработчиков показали, что спецификация протокола сложна и порой неясна. Особенно важно, что в [RFC3095] неочевидно чёткое разделение архитектуры и профилей, что также затрудняет разработку дополнительных профилей. Поэтому этот документ явно определяет архитектуру ROHC, а сопровождающий документ [RFC5225] — переработанные версии профилей сжатия RFC 3095.

4.4. Рабочие характеристики канала ROHC

Устойчивое сжатие заголовков применимо ко многим технологиям каналов. Архитектура ROHC достаточно гибка, чтобы профили могли обслуживать широкий спектр приложений. Ниже перечислены некоторые рабочие характеристики канала ROHC (см. также [RFC3759]).

Мультиплексирование в одном логическом канале

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

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

Канальный уровень с поддержкой канала ROHC должен предоставлять способ установления параметров канала сжатия заголовков (см. раздел 5.1). Это можно сделать посредством согласования, статической настройки или внешней сигнализации.

Определение типа пакета

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

Доставка вне порядка между конечными точками сжатия

Каждый профиль определяет собственный уровень устойчивости, в том числе допустимость перестановки пакетов до и особенно между конечными точками сжатия, если такая допустимость предусмотрена.

Для профилей [RFC3095] требуется, чтобы канал между компрессором и декомпрессором сохранял порядок доставки пакетов: их определения предполагают, что декомпрессор всегда получает пакеты в том порядке, в каком их отправил компрессор. Влияние перестановки на работу этих профилей описано в [RFC4224]. Однако перестановка до точки сжатия обрабатывается: профили не предполагают, что компрессор получает пакеты по порядку.

Определения профилей ROHCv2 [RFC5225] предполагают, что декомпрессор может получать пакеты вне порядка отправки компрессором. Перестановка до точки сжатия также учитывается.

Дублирование пакетов

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

Формирование кадров

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

Обнаружение ошибок и защита

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

4.5. Сжатие и главный порядковый номер (MSN)

Сжатие полей заголовка основано на установлении функции от порядкового номера, называемого главным порядковым номером (MSN). Эта функция описывает характер изменения поля в зависимости от изменения MSN.

Примеры характера изменения: монотонное увеличение поля или увеличение на небольшую величину, редкое изменение и неизменность в течение всей жизни потока; в последнем случае функция от MSN эквивалентна постоянному значению.

Компрессор сначала устанавливает функции для каждого поля заголовка, затем надёжно передаёт MSN. Если характер изменения поля не соответствует установленной функции, то есть её результат отличается от значения поля сжимаемого заголовка, можно передать дополнительную информацию для обновления параметров функции.

MSN определяется отдельно для каждого профиля. Он может выводиться непосредственно из одного из полей сжимаемого протокола, например RTP SN [RFC5225], либо создаваться и поддерживаться компрессором, например MSN для сжатия UDP в профиле 0x0102 [RFC5225] или MSN в ROHC-TCP [RFC4996].

4.6. Статическая и динамическая части контекста

Концептуально контекст сжатия можно разделить на две части — статическую и динамическую, каждая из которых основана на свойствах сжимаемых полей.

Статическая часть содержит сведения, необходимые для сжатия и восстановления полей, характер изменения которых классифицирован как STATIC, STATIC-KNOWN или STATIC-DEF, как описано в разделе 4.1.

Динамическая часть содержит состояние для всех остальных полей, то есть относящихся к классу CHANGING.

5. Архитектура ROHC (нормативный раздел)

Этот раздел нормативно определяет общие для всех профилей ROHC части, то есть архитектуру. Она задаёт требования и функциональность канала ROHC, в том числе обработку нескольких потоков сжатых пакетов в одном канале.

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

5.1. Канал ROHC

5.1.1. Контексты и их идентификаторы

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

Контекст считается новым, когда CID впервые после создания канала ROHC связывается с профилем либо когда при получении IR (но не IR-DYN) CID связывается с профилем, отличным от профиля в контексте.

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

Пространство CID может быть малым — значения от 0 до 15 — или большим — значения от 0 до 2^14 − 1 = 16383. До отправки любого сжатого пакета по каналу ROHC ДОЛЖНО быть установлено, возможно путём согласования, является пространство CID большим или малым.

Для каждого канала используется отдельное пространство CID: CID 3 в канале A и CID 3 в канале B не обозначают один контекст, даже если конечные точки обоих каналов находятся на одних и тех же узлах. В частности, идентификаторы любой пары каналов ROHC не связаны; два связанных канала ROHC, служащих каналами обратной связи друг для друга, даже не обязаны иметь пространства CID одинакового размера.

5.1.2. Параметры канала

Канал ROHC основан на ряде параметров, входящих в установленное состояние канала и состояние отдельных контекстов. Состояние канала ROHC ДОЛЖНО быть установлено до отправки первого пакета ROHC; для этого могут использоваться протоколы согласования канального уровня (см. также [RFC3241], где описан вариант согласования параметров ROHC для PPP). Ниже некоторые сведения о состоянии канала описаны абстрактно.

LARGE_CIDS: логическое значение. Если оно ложно, используется малое представление CID — 0 октетов или один октет префикса для CID от 0 до 15. Если истинно, используется большое представление — один или два встроенных октета CID для значений от 0 до 16383. См. также разделы 5.1.1 и 5.2.1.3.

MAX_CID: неотрицательное целое число, наибольший номер CID, используемый компрессором. Этот параметр не связан напрямую с LARGE_CIDS, но фактически дополнительно им ограничен. Значение означает согласие декомпрессора предоставить достаточно памяти как минимум для MAX_CID+1 контекстов; декомпрессор ДОЛЖЕН сохранять установленные контексты в этом пространстве до повторного использования CID для создания нового контекста либо до закрытия канала.

PROFILES: множество неотрицательных целых чисел, каждое из которых обозначает профиль, поддерживаемый компрессором и декомпрессором. Профиль обозначается 16-битным значением, где 8 младших битов указывают сам профиль, а 8 старших — его вариант. Формат сжатого заголовка ROHC определяет профиль только по 8 младшим битам; поэтому, если каналу доступно несколько вариантов одного профиля, множество PROFILES после согласования НЕ ДОЛЖНО содержать более одного варианта этого профиля. Компрессор НЕ ДОЛЖЕН использовать профиль, не входящий в PROFILES.

FEEDBACK_FOR: необязательная ссылка на канал ROHC в обратном направлении между теми же конечными точками сжатия. Если параметр задан, он указывает, к какому другому каналу ROHC относится любая обратная связь, отправляемая по этому каналу (см. [RFC3759]).

MRRU: неотрицательное целое число, максимальный размер восстанавливаемой единицы приёма. Это размер в октетах наибольшей восстановленной единицы, которую декомпрессор должен собрать из сегментов (см. раздел 5.2.5), включая CRC сегментации. Если согласовано MRRU = 0, сегментация в канале НЕ ДОЛЖНА использоваться, а полученные сегменты декомпрессор ДОЛЖЕН отбрасывать.

5.1.3. Сохранение контекстов декомпрессора

В составе согласованных параметров канала компрессор и декомпрессор с помощью MAX_CID договорились о наибольшем используемом номере CID. Соглашаясь с MAX_CID, декомпрессор также соглашается предоставить память как минимум для MAX_CID+1 контекстов. Установленный контекст с CID в пределах согласованного пространства СЛЕДУЕТ сохранять до повторного использования CID, закрытия канала или повторного согласования параметров.

5.2. Пакеты ROHC и их типы

В схемах этого раздела для различных типов пакетов, форматов и полей ROHC используются следующие обозначения: двоеточие «:» обозначает необязательную часть, косая черта «/» — переменную длину.

Схема обозначения типов пакетов ROHC предусматривает необязательное заполнение, тип пакета обратной связи, необязательный октет Add-CID с четырьмя битами CID и простой механизм сегментации и сборки.

Следующие типы пакетов зарезервированы на уровне архитектуры ROHC:

11100000 — заполнение
1110nnnn — октет Add-CID (nnnn = CID от 0x1 до 0xF)
11110 — обратная связь
11111000 — пакет IR-DYN
1111110 — пакет IR
1111111 — сегмент

Другие типы пакетов могут определяться и использоваться отдельными профилями:

0, 10, 110, 1111101, 11111001 — доступны, архитектурой ROHC не зарезервированы.

5.2.1. Общий формат пакетов ROHC

Общий формат пакета ROHC состоит из следующих частей в указанном порядке: необязательное заполнение (Padding), необязательная обратная связь (Feedback), необязательный заголовок (Header), необязательная полезная нагрузка (Payload).

Padding: любое количество октетов заполнения, в том числе ноль; формат октета определён в разделе 5.2.1.1.

Feedback: любое количество элементов обратной связи, в том числе ноль; формат элемента определён в разделе 5.2.4.1.

Header: зависящий от профиля заголовок CO (раздел 5.2.1.3), заголовок IR или IR-DYN (раздел 5.2.2) либо сегмент ROHC (раздел 5.2.5). Пакет ROHC содержит не более одного заголовка; он может отсутствовать, если пакет содержит только обратную связь.

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

ДОЛЖНО присутствовать хотя бы одно из полей Feedback и Header.

5.2.1.1. Формат октета заполнения

Октет заполнения: 11100000.

Примечание. Октет заполнения НЕ ДОЛЖЕН интерпретироваться как октет Add-CID для CID 0.

5.2.1.2. Формат октета Add-CID

Октет Add-CID состоит из четырёх битов 1110 и четырёх битов CID. Значения CID от 0x1 до 0xF обозначают идентификаторы от 1 до 15.

Примечание. Октет заполнения внешне похож на октет Add-CID для CID 0.

5.2.1.3. Общий формат заголовка

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

: октет Add-CID :           если CID 1–15 и пространство CID малое
| указание типа | тело |    1 октет: x бит типа и 8−x бит тела
/ 0, 1 или 2 октета CID /   1 или 2 октета при большом пространстве CID
/ тело /                    переменная длина

Указание типа: тип пакета ROHC.

Тело: интерпретируется согласно указанию типа пакета и сведениям CID в соответствии с определением отдельных профилей.

Таким образом, заголовок начинается с указания типа пакета либо с октета Add-CID, сразу за которым следует указание типа.

Если для канала ROHC настроено малое пространство CID:

• Если непосредственно перед указанием типа пакета находится Add-CID, пакет имеет CID из этого октета; иначе его CID равен 0.
• Малый CID со значением 0 представляется нулём битов. Поэтому поток с CID 0 не несёт накладных расходов CID в сжатом заголовке; заголовок начинается с указания типа.
• Малый CID от 1 до 15 представляется октетом Add-CID, как описано выше. Заголовок начинается с Add-CID, за которым следует указание типа.
• Большой CID в заголовке отсутствует.

Если настроено большое пространство CID, большой CID присутствует всегда и представляется по схеме кодирования раздела 5.3.2, ограниченной двумя октетами. Заголовок при этом начинается с указания типа.

5.2.2. Типы пакетов инициализации и обновления (IR)

Типы пакетов IR содержат идентификатор профиля, который определяет, как интерпретировать остальную часть заголовка. Они также связывают профиль с контекстом. Сохранённый параметр профиля дополнительно определяет синтаксис и семантику идентификаторов типов и типов пакетов, используемых с конкретным контекстом.

Пакеты IR и IR-DYN всегда обновляют контекст для всех содержащихся в заголовке полей, обновляющих контекст. Они никогда не очищают его, кроме случаев инициализации нового контекста (раздел 5.1.1) или когда профиль, указанный в поле Profile, предписывает иное.

5.2.2.1. Формат заголовка ROHC IR

Заголовок IR связывает CID с профилем и обычно также инициализирует контекст. Обычно он может также обновить весь контекст или его часть. Общий формат заголовка IR:

: октет Add-CID :              если CID 1–15 и пространство CID малое
| 1 1 1 1 1 1 0 | x |         октет типа IR
/ 0–2 октета CID /             1 или 2 октета при большом пространстве CID
| Profile |                    1 октет
| CRC |                        1 октет
/ сведения профиля /           переменная длина

x: информация, зависящая от профиля; интерпретируется согласно профилю в поле Profile заголовка IR.

Profile: профиль, связанный с CID. В заголовке IR идентификатор профиля сокращён до восьми младших битов (раздел 5.1.2).

CRC: восьмибитный CRC (раздел 5.3.1.1).

Сведения профиля: содержимое этой части заголовка IR определяется отдельными профилями и интерпретируется согласно профилю из поля Profile.

5.2.2.2. Формат заголовка ROHC IR-DYN

В отличие от заголовка IR, заголовок IR-DYN никогда не может инициализировать неинициализированный контекст. Однако он может изменить профиль, связанный с контекстом, если профиль, указанный в заголовке IR-DYN, это допускает. Поэтому данный тип пакета также зарезервирован на уровне архитектуры. Заголовок IR-DYN обычно также инициализирует или обновляет части контекста. Его общий формат:

: октет Add-CID :              если CID 1–15 и пространство CID малое
| 1 1 1 1 1 0 0 0 |           октет типа IR-DYN
/ 0–2 октета CID /             1 или 2 октета при большом пространстве CID
| Profile |                    1 октет
| CRC |                        1 октет
/ сведения профиля /           переменная длина

Profile: профиль, связанный с CID; сокращается так же, как в пакетах IR.

CRC: восьмибитный CRC (раздел 5.3.1.1).

Сведения профиля: содержимое этой части заголовка IR-DYN определяется отдельными профилями и интерпретируется согласно профилю из поля Profile.

5.2.3. Начальная обработка декомпрессором ROHC

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

При получении пакета IR его обработка определяется указанным в нём профилем.

• Если проверка целостности заголовка по восьмибитному CRC не удалась, пакет НЕ ДОЛЖЕН восстанавливаться и доставляться верхним уровням. Если в контексте указан профиль, его логика определяет, какую обратную связь отправить, если она нужна. Если профиль в контексте не указан, выбор обратной связи остаётся за реализацией. Однако может быть уместно больше ничего не предпринимать, поскольку причиной ошибки могла стать любая часть защищённого CRC заголовка IR.

При получении пакета IR-DYN его обработка определяется указанным в нём профилем.

• Если проверка целостности заголовка по восьмибитному CRC не удалась, пакет НЕ ДОЛЖЕН восстанавливаться и доставляться верхним уровням. Если в контексте указан профиль, его логика определяет необходимую обратную связь. Если профиль не указан, выбор остаётся за реализацией. Однако может быть уместно не предпринимать дальнейших действий, поскольку причиной ошибки могла стать любая часть защищённого CRC заголовка IR-DYN.
• Если контекст ещё не инициализирован, пакет НЕ ДОЛЖЕН восстанавливаться и доставляться верхним уровням. Логика профиля, указанного в заголовке IR-DYN, если он подтверждён восьмибитным CRC, определяет необходимую обратную связь.

При ошибке разбора пакета любого типа декомпрессор ДОЛЖЕН отбросить его без дальнейшей обработки. Например, при использовании большого пространства CID сжатый заголовок содержит поле CID с самодокументируемым кодированием переменной длины по разделу 5.3.2. Если поле начинается с 110 или 111, декомпрессор получит ошибку разбора, поскольку это поле нельзя кодировать более чем двумя октетами.

РЕКОМЕНДУЕТСЯ, чтобы профили запрещали декомпрессору пытаться восстановить пакеты, содержащие только трёхбитный CRC, после признания недействительной части или всего динамического контекста до тех пор, пока пакет с достаточными сведениями о динамических полях не будет получен, восстановлен и успешно проверен семи- или восьмибитным CRC.

5.2.4. Обратная связь ROHC

Обратная связь переносит информацию от декомпрессора к компрессору. Её можно отправлять по каналу ROHC, работающему в том же направлении, что и обратная связь.

Общий формат пакета ROHC позволяет передавать обратную связь по каналу ROHC отдельными вставленными пакетами, присоединением к другим пакетам или сочетанием обоих способов (см. [RFC3759]). Этому способствуют следующие свойства.

Зарезервированный тип пакета: тип пакета обратной связи зарезервирован на уровне архитектуры и может переносить информацию обратной связи переменной длины.

Информация CID: обратная связь, отправленная по определённому каналу, передаётся компрессору, связанному с обратной связью этого канала, и интерпретируется им. Поэтому каждый элемент обратной связи содержит CID канала, для которого она отправляется. Таким образом, схема обратной связи ROHC требует, чтобы канал передавал обратную связь не более чем одному компрессору. Способ связывания компрессора с обратной связью конкретного канала выходит за рамки этой спецификации. См. также [RFC3759].

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

Связь между парами компрессора и декомпрессора, работающими в противоположных направлениях для обмена присоединяемой и/или вставляемой обратной связью, СЛЕДУЕТ сохранять в течение жизни канала ROHC. В противном случае РЕКОМЕНДУЕТСЯ уведомить компрессор о недоступности канала обратной связи: после этого компрессору СЛЕДУЕТ начать сжатие заново, создав новый контекст для каждого потока, и СЛЕДУЕТ использовать значение CID, ранее не связанное с профилем, применяемым для сжатия потока.

5.2.4.1. Формат обратной связи ROHC

ROHC определяет три категории сообщений обратной связи: подтверждение ACK, отрицательное подтверждение NACK и NACK для всего контекста STATIC-NACK. В зависящей от профиля информации обратной связи могут определяться другие типы сведений.

ACK подтверждает успешное восстановление пакета и указывает, что декомпрессор считает свой контекст действительным.

NACK указывает, что декомпрессор считает часть или всю динамическую часть контекста недействительной.

STATIC-NACK указывает, что декомпрессор считает весь статический контекст недействительным или что он не был установлен.

Обратная связь, отправленная по каналу ROHC, состоит из одного или нескольких последовательно объединённых элементов следующего формата:

| 1 1 1 1 0 | Code |      тип обратной связи, 1 октет
: Size :                  если Code = 0
: октет Add-CID :         для малого пространства CID, если CID ≠ 0
/ большой CID /           1–2 октета для большого пространства CID
/ данные FEEDBACK /       переменная длина

Code: значение 0 указывает на наличие октета Size; значения 1–7 указывают общий размер поля данных FEEDBACK и поля CID, если оно имеется, в октетах.

Size: общий размер поля данных FEEDBACK и поля CID, если оно имеется, в октетах.

Данные FEEDBACK: FEEDBACK-1 или FEEDBACK-2, описанные ниже.

Сведения CID в элементе обратной связи указывают контекст, для которого она отправлена. Параметр LARGE_CIDS, определяющий наличие большого CID, берётся из состояния канала компрессора-получателя, а не канала, переносящего обратную связь.

Поле большого CID, если присутствует, кодируется согласно разделу 5.3.2 и НЕ ДОЛЖНО занимать более двух октетов.

Поле данных FEEDBACK может иметь один из двух форматов.

FEEDBACK-1: один октет информации, зависящей от профиля.

FEEDBACK-2: не менее двух октетов; первые два бита — Acktype, остальные содержат информацию, зависящую от профиля.

Acktype: 0 — ACK; 1 — NACK; 2 — STATIC-NACK; 3 зарезервировано и НЕ ДОЛЖНО использоваться, иначе разобрать поле невозможно.

5.2.5. Сегментация ROHC

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

5.2.5.1. Замечания по использованию сегментации

Протокол сегментации ROHC не отличается особой эффективностью. Он не предназначен для замены функций сегментации канального уровня; их СЛЕДУЕТ использовать, когда они доступны и эффективны для решаемой задачи.

Протокол сегментации ROHC разработан исходя из предположения о доставке пакетов по порядку между компрессором и декомпрессором; для обнаружения ошибок используется только CRC, порядковые номера отсутствуют. Если доставку по порядку гарантировать нельзя, сегментация ROHC НЕ ДОЛЖНА использоваться.

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

5.2.5.2. Протокол сегментации

Сегментация ROHC применяется к сочетанию полей Header и Payload пакета ROHC, определённых в разделе 5.2.1.

Формат сегмента:

| 1 1 1 1 1 1 1 | F |  тип сегмента
/ Segment /            сегмент переменной длины

F: бит последнего сегмента. Установленное значение указывает, что это последний сегмент восстанавливаемой единицы.

Перед октетом типа сегмента могут находиться заполнение и/или обратная связь. Отдельного CID для каждого сегмента нет, но информация CID, конечно, является частью восстановленной единицы. Восстановленная единица НЕ ДОЛЖНА содержать заполнение, сегменты или обратную связь.

Получив последний сегмент, декомпрессор собирает сегмент из этого пакета и непосредственно предшествовавшие ему непоследние сегменты в одну восстановленную единицу в порядке получения. Все сегменты одной единицы должны поступить декомпрессору последовательно и в правильном порядке. Если за непоследним сегментом непосредственно следует пакет ROHC другого типа, сборка текущей единицы прерывается, и декомпрессор ДОЛЖЕН отбросить уже полученные в этом канале непоследние сегменты.

Восстановленная единица состоит из заголовка Header, необязательной полезной нагрузки Payload (оба см. в разделе 5.2.1) и четырёх октетов CRC. CRC — 32-битный, вычисляемый с полиномом из раздела 5.3.1.4.

Если восстановленная единица занимает не более четырёх октетов, проверка CRC не проходит либо её размер превышает параметр канала MRRU (раздел 5.1.2), декомпрессор ДОЛЖЕН её отбросить. Если проверка CRC успешна, единицу можно обработать далее.

5.3. Общие методы кодирования

5.3.1. CRC сжатия заголовков, охват и полиномы

В разделе описано вычисление CRC, используемых ROHC. Для всех CRC применяется тот же алгоритм, что и в [RFC1662], определённый в приложении A этого документа, с полиномами, указанными далее.

5.3.1.1. Восьмибитный CRC в заголовках IR и IR-DYN

Охват восьмибитного CRC в заголовках IR и IR-DYN зависит от профиля, но ДОЛЖЕН включать как минимум начальную часть заголовка до поля Profile включительно, в том числе CID или октет Add-CID. Обратная связь и заполнение не являются частью Header (раздел 5.2.1) и поэтому не включаются в расчёт CRC. В качестве практического правила для спецификаций профилей: любую другую информацию, инициализирующую контекст декомпрессора, также СЛЕДУЕТ защищать CRC.

Точнее, восьмибитный CRC охватывает не только и не целиком исходный несжатый заголовок; поэтому он не позволяет декомпрессору проверить попытку восстановления или правильность всего контекста. Однако успешная проверка обеспечивает достаточную устойчивость для обновления контекста декомпрессора информацией из заголовка IR или IR-DYN.

Полином восьмибитного CRC: C(x) = 1 + x + x^2 + x^8.

При вычислении поле CRC в заголовке устанавливается в ноль, а начальное содержимое регистра CRC — во все единицы.

5.3.1.2. Трёхбитный CRC в сжатых заголовках

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

Полином трёхбитного CRC: C(x) = 1 + x + x^3.

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

5.3.1.3. Семибитный CRC в сжатых заголовках

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

Полином семибитного CRC: C(x) = 1 + x + x^2 + x^3 + x^6 + x^7.

Семибитный CRC позволяет декомпрессору проверить результат попытки восстановления более крупного сжатого заголовка и обеспечивает достаточную защиту для подтверждения восстановления контекста. Он достаточно надёжен, чтобы считать восстановление успешным по одному восстановленному заголовку; поэтому профили могут разрешать восстановление заголовка с семибитным CRC, когда часть контекста декомпрессора считается недействительной.

5.3.1.4. 32-битный CRC сегментации

32-битный CRC используется схемой сегментации для проверки восстановленной единицы и поэтому вычисляется по сегментированной единице, то есть полям Header и Payload пакета ROHC. Начальное содержимое регистра CRC устанавливается во все единицы.

Полином 32-битного CRC:

C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
       x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32

Назначение 32-битного CRC — проверка восстановленной единицы.

5.3.2. Самоописываемые значения переменной длины

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

Первый бит 0: 1 октет; передаётся 7 битов; десятичное значение до 127; закодированные октеты в шестнадцатеричной записи от 00 до 7F.

Первые биты 10: 2 октета; передаётся 14 битов; значение до 16 383; закодированные октеты от 80 00 до BF FF.

Первые биты 110: 3 октета; передаётся 21 бит; значение до 2 097 151; закодированные октеты от C0 00 00 до DF FF FF.

Первые биты 111: 4 октета; передаётся 29 битов; значение до 536 870 911; закодированные октеты от E0 00 00 00 до FF FF FF FF.

5.4. ROHC UNCOMPRESSED — без сжатия (профиль 0x0000)

В разделе описан профиль ROHC без сжатия. Его идентификатор — 0x0000.

Профиль 0x0000 позволяет отправлять IP-пакеты без сжатия. Это можно использовать для любого пакета, для которого среди поддерживаемых каналом ROHC профилей нет подходящего профиля сжатия или сжатие которого по какой-либо причине нежелательно.

После инициализации единственные накладные расходы при отправке пакетов профилем 0x0000 равны размеру CID. Если несжатые пакеты встречаются часто, профилю 0x0000 следует назначить CID размером ноль или один октет. Профиль 0x0000 СЛЕДУЕТ связывать не более чем с одним CID.

5.4.1. Пакет IR

Пакет инициализации и обновления IR профиля 0x0000 имеет следующий формат заголовка:

: октет Add-CID :           для малого пространства CID, если CID ≠ 0
| 1 1 1 1 1 1 0 | res |
/ 0–2 октета CID /          1–2 октета для большого пространства CID
| Profile = 0x00 |          1 октет
| CRC |                     1 октет

res: ДОЛЖЕН быть установлен в ноль; иначе декомпрессор ДОЛЖЕН отбросить пакет.

Profile: 0x00.

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

Полезная нагрузка пакета IR может содержать необязательный IP-пакет переменной длины. Несжатый IP-пакет может включаться в пакет IR; декомпрессор определяет его наличие по длине пакета IR.

5.4.2. Обычный пакет

Обычный пакет — обычный IP-пакет с информацией CID. Соответствующие Header и Payload из раздела 5.2.1 имеют формат:

: октет Add-CID :           для малого пространства CID, если CID ≠ 0
| первый октет IP-пакета |
/ 0–2 октета CID /          1–2 октета для большого пространства CID
/ остальная часть IP-пакета /  переменная длина

Первый октет IP-пакета начинается с битовой последовательности 0100 для IPv4 или 0110 для IPv6. Это не конфликтует ни с одним зарезервированным типом пакета.

Если канал использует малые CID, а профиль 0x0000 связан с CID > 0, IP-пакету предшествует октет Add-CID. При использовании больших CID идентификатор размещается начиная со второго октета объединённого формата Header/Payload, показанного выше.

Как и любой другой пакет ROHC, обычный пакет может нести заполнение и/или обратную связь перед объединёнными Header и Payload.

5.4.3. Инициализация контекста

Компрессор инициализирует статический контекст, связанный с профилем UNCOMPRESSED, отправляя пакеты IR (раздел 5.4.1). При инициализации контекста РЕКОМЕНДУЕТСЯ отправлять пакеты IR до появления достаточной уверенности, что декомпрессор успешно получил хотя бы один из них. Например, такая уверенность может основываться на обратной связи декомпрессора или знании характеристик канала.

Компрессору СЛЕДУЕТ периодически отправлять пакеты IR для контекста профиля UNCOMPRESSED, по крайней мере до получения обратной связи декомпрессора для этого контекста. После получения обратной связи компрессор МОЖЕТ прекратить периодическую отправку IR.

5.4.4. Работа декомпрессора

Получив пакет IR, декомпрессор сначала проверяет его заголовок с помощью восьмибитного CRC.

• Если заголовок не прошёл проверку, декомпрессор НЕ ДОЛЖЕН передавать IP-пакет верхним уровням.
• Если проверка успешна, декомпрессор: 1) инициализирует контекст, если у него ещё нет действительного контекста для указанного CID, связанного с указанным профилем; 2) передаёт IP-пакет верхним уровням, если он присутствует; 3) МОЖЕТ отправить ACK.

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

Если получен обычный пакет и у декомпрессора есть действительный контекст, IP-пакет извлекается и передаётся верхним уровням.

5.4.5. Обратная связь

Единственный тип обратной связи, определённый профилем 0x0000, — ACK в формате FEEDBACK-1 из раздела 5.2.4.1, где значение октета, зависящего от профиля, равно 0. Формат FEEDBACK-2 для профиля 0x0000 не определён.

6. Обзор профиля ROHC (информационный раздел)

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

Раздел 5 подробно определяет архитектуру ROHC. В настоящем разделе приводится информационный обзор элементов, составляющих спецификацию профиля. Нормативное определение отдельных профилей выходит за рамки этого документа.

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

Форматы пакетов:

• Расположение битов при передаче. Профиль определяет размещение битов в определяемых им специфичных типах пакетов и в специфичных частях общих для всех профилей типов пакетов, например IR и IR-DYN.
• Кодирование полей. Биты и группы битов из формата пакета, называемые сжатыми полями, представляют результат метода кодирования, специфичного для этого поля в конкретном формате пакета. Профиль определяет эти методы.
• Свойства обновления. Специфичные для профиля форматы пакетов могут по-разному обновлять состояние декомпрессора. Профиль определяет, как отдельные поля или целые типы пакетов профиля обновляют контекст декомпрессора.
• Проверка. Пакеты, обновляющие состояние декомпрессора, проверяются для предотвращения неправильного обновления контекста. Профиль определяет механизмы проверки восстановления пакета.

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

• Логика устойчивости. Пакеты между компрессором и декомпрессором могут теряться или переставляться. Профиль определяет механизмы минимизации последствий и предотвращения распространения повреждений.
• Механизм восстановления. Несмотря на логику устойчивости, нарушения всё же могут привести к неудаче восстановления пакетов и даже повреждению контекста декомпрессора. Профиль определяет механизмы восстановления контекста, в том числе логику обратной связи, если она используется.

7. Благодарности

Авторы выражают признательность всем участникам прежней работы над ROHC, особенно авторам RFC 3095 [RFC3095], который служит технической основой этого документа. Благодарим также всех, кто участвовал в подготовке документа исправлений и уточнений RFC 3095 [RFC4815]: применимые технические материалы из него включены сюда. Благодарим Jani Juvan за обнаружение несоответствия между структурой обратной связи в [RFC4995] и [RFC3095], из-за которого понадобилось обновление [RFC4995].

Carl Knutsson, Biplab Sarkar и Robert Stangarone проверяли документ во время последнего обсуждения в рабочей группе. Также благодарим Bert Wijnen и Brian Carpenter за замечания во время последнего обсуждения в IETF.

8. Вопросы IANA

Реестр IANA «Идентификаторы профилей устойчивого сжатия заголовков (ROHC)» [ROHC-ids] создан в RFC 3095 [RFC3095]. Политика назначения, изложенная в RFC 3095, следующая.

Идентификатор профиля ROHC — неотрицательное целое число. Во многих протоколах согласования он представляется 16-битным значением. Из-за способа сокращения идентификатора в пакетах ROHC восемь младших битов имеют особое значение: два идентификатора с одинаковыми восемью младшими битами следует назначать только тогда, когда больший предназначен для замены меньшего. Чтобы подчеркнуть эту связь, идентификаторы профилей следует приводить в шестнадцатеричном виде, например 0x1234 заменяет 0x0A34.

Согласно политикам [RFC5226], для назначения новых значений идентификатора профиля IANA применяет правило Specification Required: значения и их смысл должны быть документированы в RFC или другом постоянном и общедоступном источнике достаточно подробно, чтобы независимые реализации могли взаимодействовать. В восьми младших битах диапазон от 0 до 127 зарезервирован для спецификаций IETF на пути стандартизации; диапазон от 128 до 254 доступен для других спецификаций, удовлетворяющих этому требованию, например информационных RFC. Значение 255 зарезервировано для будущего расширения настоящей спецификации.

К моменту публикации были назначены следующие идентификаторы:

Идентификатор  Применение                 Источник
0x0000         ROHC без сжатия           RFC 5795
0x0001         ROHC RTP                  RFC 3095
0x0002         ROHC UDP                  RFC 3095
0x0003         ROHC ESP                  RFC 3095
0x0004         ROHC IP                   RFC 3843
0x0005         ROHC LLA                  RFC 3242
0x0105         ROHC LLA с режимом R      RFC 3408
0x0006         ROHC TCP                  RFC 4996
0x0007         ROHC RTP/UDP-Lite         RFC 4019
0x0008         ROHC UDP-Lite             RFC 4019
0x0101         ROHCv2 RTP                RFC 5225
0x0102         ROHCv2 UDP                RFC 5225
0x0103         ROHCv2 ESP                RFC 5225
0x0104         ROHCv2 IP                 RFC 5225
0x0107         ROHCv2 RTP/UDP-Lite       RFC 5225
0x0108         ROHCv2 UDP-Lite           RFC 5225

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

9. Вопросы безопасности

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

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

Атаки типа «отказ в обслуживании» возможны, если нарушитель способен внедрять в канал, например, поддельные пакеты IR, IR-DYN или обратной связи и тем самым снижать эффективность сжатия. Однако способность внедрять произвольные пакеты на канальном уровне создаёт дополнительные проблемы безопасности, значительно превосходящие проблемы, связанные со сжатием заголовков.

10. Ссылки

10.1. Нормативные ссылки

[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2. Информационные ссылки

[CRTP-eval]  Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro,
                ""Evaluation of CRTP Performance over Cellular Radio
                Networks", IEEE Personal Communication Magazine, Volume
                7, number 4, pp. 20-25, August 2000.", 2000.
[RFC0768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                August 1980.
[RFC0791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
                September 1981.
[RFC0793]    Postel, J., "Transmission Control Protocol", STD 7,
                RFC 793, September 1981.
[RFC1144]    Jacobson, V., "Compressing TCP/IP headers for low-speed
                serial links", RFC 1144, February 1990.
[RFC1662]    Simpson, W., "PPP in HDLC-like Framing", STD 51,
                RFC 1662, July 1994.
[RFC2460]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", RFC 2460, December 1998.
[RFC2507]    Degermark, M., Nordgren, B., and S. Pink, "IP Header
                Compression", RFC 2507, February 1999.
[RFC2508]    Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
                Headers for Low-Speed Serial Links", RFC 2508,
                February 1999.
[RFC3095]    Bormann, C., Burmeister, C., Degermark, M., Fukushima,
                H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
                Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
                K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust
                Header Compression (ROHC): Framework and four profiles:
                RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3096]    Degermark, M., "Requirements for robust IP/UDP/RTP
                header compression", RFC 3096, July 2001.
[RFC3241]    Bormann, C., "Robust Header Compression (ROHC) over
                PPP", RFC 3241, April 2002.
[RFC3545]    Koren, T., Casner, S., Geevarghese, J., Thompson, B.,
                and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links
                with High Delay, Packet Loss and Reordering", RFC 3545,
                July 2003.
[RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
                Jacobson, "RTP: A Transport Protocol for Real-Time
                Applications", STD 64, RFC 3550, July 2003.
[RFC3759]    Jonsson, L-E., "RObust Header Compression (ROHC):
                Terminology and Channel Mapping Examples", RFC 3759,
                April 2004.
[RFC4224]    Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
                Header Compression (ROHC): ROHC over Channels That Can
                Reorder Packets", RFC 4224, January 2006.
[RFC4815]    Jonsson, L-E., Sandlund, K., Pelletier, G., and P.
                Kremer, "RObust Header Compression (ROHC): Corrections
                and Clarifications to RFC 3095", RFC 4815,
                February 2007.
[RFC4995]    Jonsson, L-E., Pelletier, G., and K. Sandlund, "The
                RObust Header Compression (ROHC) Framework", RFC 4995,
                July 2007.
[RFC4996]    Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West,
                "RObust Header Compression (ROHC): A Profile for TCP/IP
                (ROHC-TCP)", RFC 4996, July 2007.
[RFC5225]    Pelletier, G. and K. Sandlund, "RObust Header
                Compression Version 2 (ROHCv2): Profiles for RTP, UDP,
                IP, ESP and UDP-Lite", RFC 5225, April 2008.
[RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.
[ROHC-ids]   IANA, "RObust Header Compression (ROHC) Profile
                Identifiers", <http://www.iana.org>.

Приложение A. Алгоритм CRC

Следующий пример демонстрирует четыре типа CRC, используемые в RFC 3095. Данные вводятся в шестнадцатеричном виде; для завершения ввода нужно нажать Control+D. Код приведён в оригинальном виде. В комментариях к нему отдельно указано, что 32-битный CRC сегментации, согласно тексту, дополняется как в PPP, в отличие от 8-, 7- и 3-битного CRC.

#!/usr/bin/perl -w
   use strict;
   #=================================
   #
   # Демонстрация CRC ROHC - Carsten Bormann cabo@tzi.org 2001-08-02
   #
   # Эта небольшая программа показывает четыре типа CRC из RFC 3095,
   # спецификации устойчивого сжатия заголовков. Введите данные
   # в шестнадцатеричной форме и нажмите Control+D.
   #
   #---------------------------------
   #
   # служебная функция
   #
   sub dump_bytes($) {
       my $x = shift;
       my $i;
       for ($i = 0; $i < length($x); ) {
     printf("%02x ", ord(substr($x, $i, 1)));
     printf("\n") if (++$i % 16 == 0);
       }
       printf("\n") if ($i % 16 != 0);
   }
#---------------------------------
   #
   # Алгоритм вычисления CRC.
   #
   sub do_crc($$$) {
       my $nbits = shift;
       my $poly = shift;
       my $string = shift;
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
       for (my $i = 0; $i < length($string); ++$i) {
         my $byte = ord(substr($string, $i, 1));
         for( my $b = 0; $b < 8; $b++ ) {
           if (($crc & 1) ^ ($byte & 1)) {
             $crc >>= 1;
             $crc ^= $poly;
           } else {
           $crc >>= 1;
           }
           $byte >>= 1;
         }
       }
printf "%2d bits, ", $nbits;
       printf "CRC: %02x\n", $crc;
   }
#---------------------------------
   #
   # Тестовая обвязка
   #
   $/ = undef;
   $_ = <>;         # читать до конца ввода
   my $string = ""; # извлечь всё похожее на шестнадцатеричные данные:
   s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
   dump_bytes($string);
#---------------------------------
   #
   # 32-битный CRC сегментации
   # Текст подразумевает дополнение, как для PPP
   # (в отличие от 8-, 7- и 3-битного CRC)
   #
   #      C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
   #             x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
   #
   do_crc(32, 0xedb88320, $string);
#---------------------------------
   #
   # 8-битный CRC IR/IR-DYN
   #
   #      C(x) = x^0 + x^1 + x^2 + x^8
   #
   do_crc(8, 0xe0, $string);
#---------------------------------
   #
   # 7-битный CRC FO/SO
   #
   #      C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
   #
   do_crc(7, 0x79, $string);
#---------------------------------
   #
   # 3-битный CRC FO/SO
   #
   #      C(x) = x^0 + x^1 + x^3
   #
   do_crc(3, 0x6, $string);

Адреса авторов

Kristofer Sandlund
   Ericsson
   Box 920
   Lulea  SE-971 28
   Sweden
Телефон: +46 (0) 8 404 41 58
   Эл. почта: kristofer.sandlund@ericsson.com
Ghyslain Pelletier
   Ericsson
   Box 920
   Lulea  SE-971 28
   Sweden
Телефон: +46 (0) 8 404 29 43
   Эл. почта: ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson
   Optand 737
   Ostersund  SE-831 92
   Sweden
Телефон: +46 76 830 03 12
   Эл. почта: lars-erik@lejonsson.com

Sandlund, et al. Standards Track [Page 41]

Перевод: RFCNET · rfcnet.ru

Original copyright notice
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Неофициальный перевод. При расхождениях см. оригинал.