Кратко

  • RFC 1473 развёл конфигурацию и рабочее состояние IP поверх PPP по разным таблицам. Административное open было событием для конечного автомата IPCP, а не обещанием, что тот достигнет Opened.
  • Изменение предпочтительного сжатия начинало действовать при следующем перезапуске линии. До завершения согласования возвращаемые протокол и номер слота были неопределёнными; после Opened они описывали параметры, но не подтверждали получение IP-пакета.

RFC 1473, опубликованный в июне 1993 года, задал управляемые объекты для IP Network Control Protocol в PPP. Авторы сознательно ограничили набор: брали переменные, необходимые для настройки и поиска неисправностей, оценивали их текущую полезность, не включали производные показатели и чисто отладочные детали.

Небольшой объём сделал документ особенно ясным. Желаемая конфигурация, результат работы конечного автомата и наблюдаемое действие в канале предстали разными классами фактов.

Команда open ещё не открывала протокол

Записываемый pppIpConfigAdminStatus выражал немедленно желаемое административное состояние IP-протокола. Значение open передавало административное событие Open конечному автомату IPCP, а close — событие Close.

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

В более позднем RFC 1661 эта независимость сохранилась. Каждый протокол сетевого уровня настраивался своим NCP, и разные NCP могли открываться и закрываться независимо. Неудача IPCP на одной PPP-линии сама по себе не определяла судьбу остальных сетевых протоколов.

Записанная настройка ждала следующего запуска

Второй записываемый объект, pppIpConfigCompression, выбирал то, что локальная сторона попытается согласовать: отсутствие сжатия либо сжатие TCP/IP-заголовков Van Jacobson. В его описании стояла временная оговорка: изменение вступает в силу при следующем перезапуске линии.

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

RFC 1332 определял саму процедуру. Опция IP-Compression-Protocol по умолчанию означала отсутствие сжатия и сообщала, какой сжатый протокол сторона способна принимать. Для двустороннего сжатия каждая сторона должна была независимо запросить приём.

Один локальный переключатель не мог доказать симметричное соглашение. Запись не доказывала перезапуск, перезапуск — принятие опции партнёром, а результат одного направления — результат другого.

До Opened число не свидетельствовало ни о чём

В рабочей таблице находились pppIpOperStatus, протокол сжатия и максимальный идентификатор слота отдельно для каждого направления. RFC 1473 разрешал считать согласованные параметры доступными только после завершения обмена опциями PPP, то есть после перехода IPCP в Opened.

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

Это строже, чем «возможно устарело». Устаревшее значение когда-то относилось к реальному событию. Неопределённое может быть нулём, остатком предыдущего запуска, начальной константой или иным выбором программы, не утверждая ничего о текущем согласовании. Корректный целочисленный ответ интерфейса ещё не создаёт корректного операционного утверждения.

После Opened значение всё равно требовало направления. local-to-remote описывал отправку локальной стороны, remote-to-local — обратный поток. Max-Slot-Id имел смысл лишь при сжатии Van Jacobson, а иначе должен был быть равен нулю. Одинаковая цифра без состояния, протокола и направления означала разные вещи.

Opened был допуском, а не квитанцией

RFC 1332 требовал, чтобы PPP вошёл в фазу протоколов сетевого уровня, а IPCP — в Opened, прежде чем стороны смогут передавать IP-пакеты. RFC 1661 уточнил: пакет соответствующего сетевого протокола, полученный до открытия NCP, следует отбросить.

Тем самым Opened действительно менял допустимое поведение. Но это оставалось состоянием автомата. Оно не указывало конкретный пакет, не показывало роста счётчика, успешного восстановления заголовка, наличия маршрута или ответа приложения.

RFC 1144 объяснял экономию на медленных последовательных линиях: повторяющиеся части TCP/IP-заголовков можно передавать компактно, опираясь на состояние соединения. Согласованная возможность, однако, не равна сжатому пакету; пакет не равен правильной реконструкции; реконструкция не равна полезной доставке.

Граница таблиц сохраняла границу полномочий

RFC 1473 вынес записываемые параметры в отдельную таблицу, которую можно было поместить в защищённое представление управления. Раздел безопасности предупреждал о риске доступа к настройке и управлению PPP. В той же серии RFC 1471 описывал управление LCP, а RFC 1472 — отдельную конфигурацию аутентификации. Универсального зелёного индикатора авторы не создавали.

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

Без этой цепочки отложенное пожелание выглядит активным, неопределённое чтение — измерением, а Opened — состоявшейся доставкой. RFC 1473 оставил важный принцип: система управления обязана обозначать не только известные факты, но и момент, когда факта ещё нет.

Источники