Кратко

  • Обычный PPP сохранял ненумерованный режим UI. RFC 1663 разрешил двум соседям добровольно согласовать Numbered Mode для одного канала: ограниченное окно, общее пространство номеров, подтверждения, таймеры и определенный возврат к UI при расхождении состояний.
  • Концы могли объявить разные окна, но обязаны были выбрать один модуль: 8 для окна меньше 8 либо 128 для большего окна. Magic-Number выбирал инициатора SABM или SABME, а не удостоверял его личность.
  • SABM/SABME и UA устанавливали только нумерованную канальную процедуру. Аутентификация, оценка качества, NCP, маршрутизация и завершение прикладной операции требовали отдельных свидетельств.

Цена потери возрастала при общем состоянии

Обычный PPP в кадрах HDLC-подобного формата использовал адрес All-Stations и управляющее значение Unnumbered Information. Пакеты оставались датаграммами. Поврежденный кадр можно было отбросить, не восстанавливая его место в последовательности средствами самого канала.

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

Рабочая группа PPP в IETF не сделала эту потребность обязательной для всех. RFC 1663, опубликованный в июле 1994 года, определил параметр LCP 11 — Numbered-Mode. Одна сторона предлагала его на этапе установления, другая принимала. Без соглашения действовал обычный UI.

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

Поля Address и Control стали переносить состояние

Numbered Mode не заменял весь кадр PPP. Protocol, Information, Padding, FCS и флаги сохраняли назначение. Нумерованная процедура LAPB из ISO 7776 меняла Address и Control. После входа в режим все кадры этого канала должны были следовать ему; произвольное смешение с UI не допускалось.

Поэтому Address-and-Control-Field Compression становилось несовместимым. В обычном режиме постоянную пару ff 03 можно было не передавать. В нумерованном режиме эти поля содержали адрес и управление последовательностью. RFC 1663 запрещал согласовывать ACFC, а RFC 1662 задавал общий принцип: нестандартные значения Address или Control требуют предварительного определения или соглашения и не могут исчезнуть как значения по умолчанию.

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

Окно выбирало не только объем, но и грамматику

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

При окне меньше 8 использовался модуль 8, при окне 8 и более — модуль 128. Стороны могли объявлять разные окна: их буферы не обязаны быть симметричными. Разные модули были запрещены. Если один конец считает в трехбитном цикле, а другой читает семибитный цикл, это не различие производительности, а несовместимый язык протокола.

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

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

Меньший Magic-Number начинал обмен

Numbered Mode требовал успешного согласования Magic-Number. После принятия конфигурации LCP сторона с меньшим числом отправляла SABM для модуля 8 или SABME для модуля 128; другая отвечала UA. Соседи определяли инициатора на основе уже согласованных значений.

При потере запроса или UA повтор ограничивали Restart Timer и счетчики LCP. Смысл UA, однако, был узким: сосед принял установление нумерованной процедуры. В архитектуре PPP за установлением канала следовали аутентификация, Link Quality Determination и настройка NCP. UA не доказывал принятие учетных данных, достаточное качество, настроенный IP, наличие маршрута или исполнение запроса службой.

Magic-Number также не был удостоверением. Он помогал различать стороны и обнаруживать закольцованный канал, но не являлся подписью или полномочием. RFC 1663 не обсуждал вопросы безопасности. Надежность соседней доставки не означала доверия к соседу.

Для утраты общего состояния существовал выход

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

Повторное согласование начиналось еще в Numbered Mode. Если параметр не удавалось согласовать снова, канал возвращался к UI до аутентификации, оценки качества и NCP. Реализация, способная к нумерации, но находящаяся в UI, при получении не-UI кадра с правильным FCS отвечала DM и немедленно перезапускала LCP. Нумерованная сторона при получении DM также переходила к UI и отправляла новый Configure-Request.

Правильный FCS сам по себе не оживлял прежнее состояние. DM и новый раунд LCP делали расхождение наблюдаемым.

Повторы были конечными. T1 задавал максимальное ожидание ответа на информационный кадр. Его рекомендовалось адаптировать к измеренному времени обхода LAPB; запасная формула учитывала длину кадра, скорость и обработку. T3 отмечал простой и должен был превышать T1. N2 ограничивал попытки для одного кадра; после превышения канал следовало завершить. Рекомендованное начальное значение — 3.

Три попытки не были универсальным законом сети. Это граница конкретной процедуры между соседями. Исчерпание N2 не объясняло причину молчания и не задавало число повторов прикладной транзакции.

Параллельные каналы не объединялись автоматически

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

RFC 1663 упоминал ISO Multi-Link, не рекомендовал его реализацию и указывал на PPP Multilink, позднее оформленный как RFC 1990. Numbered Mode восстанавливал порядок в одном канале-участнике. Multilink создавал последовательность для сборки фрагментов из нескольких каналов. Наличие одного не доказывало наличие другого.

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

Ограниченное подтверждение сохраняло точный смысл

Реестр IANA закрепляет за Numbered-Mode параметр LCP 11. Это доказывает общий словарь. Configure-Ack доказывает принятие конкретных значений в раунде. SABM или SABME с UA доказывает установление процедуры. Номера, подтверждения и повторы поддерживают выводы о кадрах этого канала. DM, перезапуск LCP или исчерпание N2 показывает утрату состояния.

Ни одна ступень не заменяет следующую. Личность подтверждают протоколы аутентификации; качество — измерения и локальная политика; сетевую конфигурацию — NCP; достижимость — наблюдения маршрутизации; результат операции — идентификаторы и ответы приложения.

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

Источники