RFC 4413 — Поведение полей TCP/IP

2.1.2. Поля заголовка IPv4

• Version — версия
• Это поле указывает номер версии протокола IP. Пакеты с отличающимися значениями этого поля должны обрабатываться разными стеками IP. Все пакеты одного потока должны, следовательно, иметь одинаковую версию IP. Это позволяет отнести поле к классу STATIC.
• Packet Length — размер пакета
• Предполагается, что информация о размере пакета обеспечивается канальным уровнем. Это поле, следовательно, относится к классу INFERRED.
• Flags — флаги

• Поле резервного флага (Reserved) должно имет значение 0 в соответствии с RFC 791 [1]. Поэтому в RFC 3095 [31] поле классифицируется как STATIC-KNOWN. Однако предполагается возможность использования зарезервированных полей в будущем. Нежелательно выбирать такое представление, которое будет препятствовать использованию профиля компрессии при изменении заголовка в результате использования резервных полей. По этой причине используется классификация поля как CHANGING. Коммуникационный профиль, естественно, может быть оптимизирован с учетом текущей ситуации, когда значение поля известно заранее (0).

  Флаг наличия дополнительных фрагментов (MF) предполагается нулевым, поскольку фрагментации в идеальном случае не ожидается. Однако следует понимать, что в некоторых сценариях работы (например, в некоторых вариантах архитектуры туннелирования) фрагментация может возникать. В общем случае, тем не менее. предполагается отсутствие фрагментации в Internet (благодаря начальному согласованию MSS и последующему применению механизма path-MTU discovery). RFC 3095 [31] указывает, для протокола RTP только первый фрагмент будет содержать заголовок транспортного уровня и последующие фрагменты будут сжиматься с использованием другого профиля. Это нормальная ситуация для TCP. Если возникает фрагментация, первый фрагмент по определению будет относительно большим для минимизации относительного размера заголовков. Последующие фрагменты будут сжиматься с использованием другого профиля. Следовательно, представляется нежелательной оптимизация фрагментирования при сжатии заголовков. Флаг наличия дополнительных фрагментов в результате классифицируется как STATIC- KNOWN.

• Fragment Offset — смещение фрагмента
• В предположении отсутствия фрагментации смещение фрагмента всегда равно нулю. Следовательно, это поле классифицируется как STATIC-KNOWN. Даже если принимать во внимание фрагментацию, только первый фрагмент будет содержать заголовок TCP и смещение фрагмента в этом заголовке будет равно нулю.
• Protocol — протокол

• Это поле обычно имеет одинаковое значение во всех пакетах одного потока. Данное поле определяет тип последующего заголовка.

  Это поле меняет свое значение лишь в случае изменения последовательности заголовков (например, вставляется или удаляется расширение заголовка или туннельный заголовок). Следовательно, поле относится к классу STATIC. Будет ли такое изменение приводить к тому, что последовательность пакетов станет трактоваться как новый поток (с точки зрения сжатия заголовков) определяется профилем. Профили ROHC должны обеспечивать возможность работы с расширенными заголовками и туннелями, но выбор стратегии не входит в задачи данного документа.

• Header Checksum — контрольная сумма заголовка

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

  Отметим, что контрольная сумма заголовка TCP защищает не все заголовки TCP/IP, а только псевдо-заголовок TCP (и данные).

  ROHC [31] использует значение CRC для проверки несжатого заголовка. С учетом необходимости проверки корректности всего заголовка TCP/IP, затрат на расчет контрольной суммы TCP с учетом всех данных и известные недостатки контрольных сумм TCP [37] дополнительная проверка является необходимой. Следовательно, весьма желательно использование дополнительной контрольной суммы (такой, как CRC) для проверки корректности декомпрессии.

• Source Addresses и Destination Addresses — адреса отправителя и получателя
• Эти поля являются частью определения потока пакетов и, следовательно, являются неизменными для конкретного потока. Таким образом, поля классифицируются как STATIC-DEF.

Общие размеры заголовков разного класса показаны на рисунке 4: