Кратко

  • В унаследованных из RFC 2509 полях TCP_SPACE и NON_TCP_SPACE ноль был максимальным идентификатором контекста, поэтому CID 0 оставался доступным — то есть контекст был один.
  • Трёхоктетная подопция 3 из RFC 3544 позволила явно задать ноль TCP- или нетипичных контекстов и тем самым отключить сжатие этого класса.

Путаница возникала из-за названия поля. TCP_SPACE и NON_TCP_SPACE не считали контексты, а задавали наибольший идентификатор в соответствующем пространстве. При максимуме 0 пространство всё ещё включало CID 0. Этого могло хватить для минимальной конфигурации, но сами поля не позволяли выразить: «не сжимать пакеты этого класса вовсе».

RFC 3544, опубликованный в июле 2003 года как Proposed Standard, пересмотрел опцию согласования PPP из RFC 2509, не меняя её прежнюю семантику. Подопция 3 добавила недостававшее различие: тип 3, длина 3 октета и однобайтовый параметр. Значение 1 означает ноль TCP-контекстов, значение 2 — ноль нетипичных контекстов. Подопция переопределяет соответствующее значение TCP_SPACE или NON_TCP_SPACE. Если включить оба варианта, сжатие отключается для всех пакетов.

Это исправление совместимости с явным переопределением, а не новое толкование нуля. Старые поля сохраняют привычный смысл; дополнительный сигнал передаёт намерение, для которого в них не было подходящего значения. Изменение семантики битов заставило бы старые и новые узлы по-разному понимать одну и ту же запись.

Два NCP согласуют параметры отдельно

PPP согласует параметры канала посредством сетевых протоколов управления — NCP. RFC 3544 задаёт одинаковый формат опции для IPv4-протокола IPCP и IPv6-протокола IPV6CP. Каждый NCP настраивает сжатие пакетов, чей внешний сетевой заголовок относится к соответствующей версии. Поэтому согласование для IPv4 и IPv6 даёт два результата плоскости управления, а не один общий переключатель.

Есть ещё нюанс: IPv4 и IPv6 разделяют пространство идентификаторов контекста, хотя параметры согласуются независимо. При разных значениях механизм сжатия должен выделять идентификаторы из общего пула, а декомпрессор — проверять состояние контекста, чтобы определить нужные параметры. TCP и нетипичная группа UDP/RTP используют отдельные пространства. Это требования протокола к работе узлов, но не свидетельство, что конкретный партнёр настроил или задействовал эту возможность.

RFC 3544 также добавил подопцию улучшенного RTP типа 2. Она согласуется вместо прежней RTP-подопции 1, а не одновременно с ней. Вместе с девятью значениями поля протокола PPP эти параметры помогают получателю распознавать класс кадра и допустимый согласованный формат. Поле протокола служит для демультиплексирования; подопция передаёт намерение конфигурации.

Согласование не доказывает работу плоскости данных

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

В самом документе отмечена соседняя неоднозначность: RFC 1332 не уточняет, описывает ли опция возможности отправителя или получателя. RFC 3544 говорит, что в соответствии с практикой предполагает: Config-Req описывает декомпрессор узла, который её отправляет. Это явно оговорённое предположение, а не нормативное уточнение RFC 1332. Более сильная трактовка скрыла бы оговорку самого документа.

У плоскости данных есть отдельное условие. IPHC применяет дельта-кодирование для TCP и RTP, поэтому сжатые пакеты опираются на общий контекст на обоих концах. Сам PPP пакеты не переставляет, поэтому механизмы защиты от перестановки по умолчанию отключены. Если используется многоклассовый Multi-Link PPP или иной механизм, который может менять порядок, пакеты одного контекста сжатия должны сохранять последовательность. Согласование формата не отменяет это транспортное ограничение.

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

Источники