РРР использует протокол управления соединением, чтобы договориться о некоторых возможностях конфигурации с партнером. Два взаимодействующих протокола РРР могут работать в различных операционных средах и могут быть сконфигурированы системными администраторами по-разному. Однако это не должно быть помехой в установлении соединения. Протокол управления соединением (LCP) как раз и призван решить эти проблемы. LCP умеет договариваться о формате инкапсуляции данных. При этом отмечаются поля, удаляемые из кадра данных при последующих транзакциях, что уменьшает объем передаваемой информации и, следовательно, увеличивает производительность. LCP меняет конфигурацию соединения “на лету”, основывая свое решение на анализе трафика и совершенно незаметно для пользователя. Другими словами, неискушенный пользователь даже не заметит, что LCP выбрал оптимальную конфигурацию канала для данного сеанса связи. В следующих абзацах мы рассмотрим формат пакетов LCP и параметры, которые LCP может изменить при установлении соединения.

Пакеты LCP

В составе РРР различают три типа пакетов: конфигурации соединения, окончания сеанса и управления соединением. Пакеты конфигурации предназначены для установления и настройки линии связи. Пакеты окончания сеанса, как следует из названия, служат для завершения сеанса связи. Пакеты управления соединением используются LCP для обслуживания и отладки установленного соединения РРР. Значение 0хС021 в поле “Протокол”, как было уже показано, означает, что в кадре РРР размещены данные LCP (рис. 3.6).

Однобайтовое поле “Код” обозначает тип пакета LCP, помещенного в кадр РРР. Однобайтовое поле “Идентификатор” протокола LCP обозначает порядковый номер пакета среди совокупности пакетов-запросов и пакетов-ответов, проходящих сквозь различные сетевые уровни, обслуживаемые РРР. Поле “Идентификатор” похоже на поле “Порядковый номер” протокола TCP. Двухбайтовое поле “Длина” протокола LCP указывает общую длину пакета LCP, включая поля “Код”, “Идентификатор”, “Длина” и собственно данных. Поле данных LCP может быть пустым (ноль байтов). Тип пакета LCP, задающийся полем “Код”, определяет формат и содержимое поля данных.            В табл. 3.1 приведены возможные значения кодов LCP, определенные на июль 1994 года.

Таблица 3.1

Значения поля "Код протокола управления соединением (LCP)"

Код LCP	Имя пакета	Тип (класс) пакета
1	Configure-Request	Конфигурация соединения (configuration)
2	Configure-Ask	Конфигурация соединения
3	Configure-Nak	Конфигурация соединения
4	Configure-Reject	Конфигурация соединения
5	Terminate-Request	Окончание сеанса (termination)
6	Terminate-Ack	Окончание сеанса
7	Code-Reject	Управление соединением (maintenance)
8	Protocol-Reject	Управление соединением
9	Echo-Request	Управление соединением
10	Echo-Reply	Управление соединением
11	Discard-Request	Управление соединением

Структура пакетов конфигурации соединения LCP

Пакеты конфигурации соединения LCP предназначены для инициализации и установления соединения по протоколу РРР. Существуют четыре разновидности пакетов: “конфигурация-запрос” (Configure-Request), “конфигурация-подтверждение” (Configure-Ack), “конфигурация-неподтверждено” (Configure-Nak) и “конфигурация-отказ” (Configure-Reject). Для открытия соединения РРР требуется послать пакет “конфигурация-запрос”. Это требование является обязательным для любой реализации протокола РРР. Поле данных пакета “конфигурация-запрос” содержит список желательных вариантов настройки соединения.

Протокол РРР, получивший пакет “конфигурация-запрос”, обязан ответить на него подобающим образом. Если список желательных вариантов настройки соединения подходит РРР по всем статьям, то в ответ высылается пакет “конфигурация-подтверждение”. Поле данных ответного пакета также содержит список вариантов конфигурации — точную копию принятого. Другими словами, ответный пакет как бы говорит: “Хорошо, все посланные тобой варианты настройки в поле данных пакета “конфигурация-запрос” принимаются. Имейте в виду, что этот пакет высылается, только когда все перечисленные варианты настройки подходят.

Если компьютер не способен выполнить какой-либо пункт желательной настройки соединения, он должен ответить пакетом “конфигурация-неподтверждено”. Поле данных этого пакета содержит список неподдерживаемых вариантов настройки. Другими словами, протокол РРР отфильтровывает список, помещая в поле данных только неудачные, с его точки зрения, параметры. Протокол LCP также разрешает помещать в поле данных пакета “конфигурация-неподтверждено” список дополнительных вариантов настройки соединения. Компьютер, получивший пакет “конфигурация-неподтверждено”, должен ответить на запрос любых дополнительных вариантов настройки.

Протокол РРР продолжает обмениваться пакетами до тех пор, пока оба участника соединения не придут к единому мнению по поводу конфигурации соединения. Модуль РРР, обнаруживший неизвестный ему вариант настройки в пакете-запросе, обязан ответить пакетом “конфигурация-отказ”. Поле данных пакета “конфигурация-отказ” содержит список только неизвестных вариантов. Разница между вариантами, помещенными в поля данных пакетов “конфигурация-отказ” и “конфигурация-неподтверждено”, состоит в том, что варианты-“отказники” не подлежат дальнейшему обсуждению. Другими словами, РРР может изменить свое мнение о ранее неподтвержденном варианте конфигурации в процессе связи. В то же время варианты, перечисленные в пакете “конфигурация-отказ”, больше никогда не будут запрашиваться.

Структура пакетов окончания сеанса LCP

Для окончания сеанса РРР использует две разновидности пакетов: “окончание-запрос” (Terminate-Request) и “окончание-подтверждено” (Terminate-Ack). Обе разновидности пакетов полностью игнорируют поле данных. Протокол РРР требует, чтобы компьютер, получивший пакет “окончание-запрос”, всегда отвечал передачей пакета “окончание-подтверждено”.

В RFC 1661 указано, что реализация РРР, которая хочет прекратить соединение, должна передавать пакет “окончание-запрос”. Однако не обязательно, что все реализации РРР ведут себя именно так. Окончание сеанса приложения, работающего непосредственно с протоколом РРР, не должно зависеть только от приема соответствующего пакета. Например, модемное соединение может внезапно разорваться, и РРР вообще не получит никакого пакета. В RFC 1661 указано, что реализация РРР должна постоянно посылать пакеты “окончание-запрос” до тех пор, пока не произойдет один из следующих трех случаев:

• Компьютер примет ответный пакет “окончание-подтверждено”.

• Низлежащий сетевой уровень определит, что дальнейшая передача данных невозможна. (Например, модем потеряет несущую.)

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

Если модуль РРР вдруг неожиданно получит непрошенный пакет “окончание-подтверждено”, он должен либо вновь договориться о соединении, либо считать, что удаленный компьютер завершил сеанс.

Структура пакетов управления соединением LCP

Пакеты управления соединением используются для управления и отладки во время сеанса связи. Определено пять разновидностей пакетов: “код-отказ” (Code-Reject), “протокол-отказ” (Protocol-Reject), “эхо-запрос” (Echo-Request), “эхо-ответ” (Echo-Reply) и “игнорировать-запрос” (Discard-Request). Пакет “код-отказ” передается модулем РРР, принявшем пакет с неизвестным полем “код”. Поле данных этого пакета (оно называется “Rejected-Packet field”) содержит копию поля данных принятого пакета с неизвестным полем “код”. Однако эта копия включает только данные из поля “информация”. Ни заголовки уровня соединения, ни контрольная сумма CRC кадра РРР туда не попадают. На рис. 3.7 приведен формат пакета “код-отказ”.

Пакет “протокол-отказ” передается по тому же самому поводу, что и “код-отказ” — в ответ на неопознанное значение поля “протокол” пакета РРР. Из рис. 3.8 видно, что пакет “протокол-отказ” содержит двухбайтовое поле, идентифицирующее неопознанный протокол, а также его “неопознанные данные” (Rejected-Information).

Поле “неопознанный протокол” содержит значение неопознанного поля “протокол” в принятом пакете. Так же, как и в предыдущем случае, поле “неопознанные данные” содержит данные только из информационного поля принятого пакета. Чтобы протестировать состояние канала связи, РРР шлет пакеты “эхо-запрос” и “эхо-ответ”. Модуль РРР, получивший пакет “эхо-запрос”, должен ответить пакетом “эхо-ответ”. Пакет “игнорировать-запрос” предназначен для тестирования канала в одном направлении: от локального до удаленного компьютера. Модуль РРР, принимающий пакеты “игнорировать-запрос”, не обращает на них никакого внимания.

Пакеты всех трех только что перечисленных типов содержат поле “магическое число” в поле данных. “Магическое число” устанавливается при конфигурации соединения и необходимо для опознавания петли на канале связи.

Варианты конфигурации соединения LCP

Варианты конфигурации соединения представляют собой набор характеристик канала связи “точка-точка”. Каждый вариант имеет значение, принимаемое по умолчанию. Протокол РРР устанавливает значение по умолчанию, если оно отсутствует в принятом пакете “конфигурация-запрос”. Значения, принимаемые по умолчанию, позволяют РРР не проводить переговоры о некоторых вариантах конфигурации. Однако в большинстве случаев выбор значения по умолчанию приводит к тому, что установленное соединение оказывается хуже по характеристикам, чем могло бы быть. На рис. 3.9 показан общий формат вариантов конфигурации LCP.

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

Тип

Длина

Данные

 1 байт        1 байт

Рис. 3.9. Общий формат вариантов конфигурации LCP

Таблица 3.2

Значения поля типа для протокола конфигурации LCP

Значение поля типа	Описание варианта конфигурации
1	Не используется (зарезервировано)
2	Максимальная длина принимаемого блока (Maximum-Receive-Unit)
3	Протокол авторизации доступа (Authentication-Protocol)
4	Протокол управления качеством (Quality-Protocol)
5	Магическое число (Magic Number)
7	Сжатие данных поля протокола (Protocol-Field-Compression)
8	Сжатие полей адреса и управления (Address-and-Control-Field Compression)

Максимальная длина принимаемого блока

Вариант конфигурации “максимальная длина принимаемого блока” (MRU) — не что иное, как максимальный размер пакета данных, который модуль РРР в состоянии принять, равный по умолчанию 1500 байт. Модуль РРР может установить MRU как больше, так и меньше значения по умолчанию. Предположим, компьютер хочет передавать блоки данных размером 2048 байтов. Если удаленный компьютер согласится работать с блоками такой длины (указывается в пакете “конфигурация-запрос”), оба они будут передавать пакеты длиной по 2048 байтов.

Нужно иметь в виду, что реализация РРР необязательно должна посылать пакеты длиной, в точности равной MRU. Вариант конфигурации MRU определяет именно максимальную длину пакета, превышать которую нельзя. РРР не обязан дополнять пакет меньшей длины пустой последовательностью данных. Он всегда может послать пакет меньшей, чем MRU, длины. Если компьютер по какой-либо причине не может работать с MRU, равным 1500 байтов, в процессе конфигурации соединения он может запросить MRU меньшего размера (рис. 3.10).

Тип

Длина

Максимальная длина пакета (MRU)

1 байт                  1 байт                   2 байта

Рис. 3.10. Формат варианта конфигурации LCP

“максимальная длина принимаемого блока” (MRU)

Значение поля длины варианта конфигурации MRU всегда равно четырем. Поле “максимальная длина принимаемого блока”, длиной в два байта, имеет значение, равное максимальному количеству байтов в информационном поле пакета данных РРР. Другими словами, размер MRU не включает служебную информацию кадра РРР, полей протокола и контрольной суммы.

Конфигурация протокола авторизации доступа

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

Для запроса того или иного протокола авторизации модуль РРР, как и раньше, шлет пакет “конфигурация-запрос” с установленным типом пакета (“запрос авторизации доступа”) и определенным типом авторизации и ждет ответа от удаленного компьютера. Если удаленный компьютер согласен установить связь с авторизацией доступа, он, как и прежде, посылает ответный пакет “конфигурация-подтверждение”. Таким образом, оба компьютера начинают сеанс с авторизации доступа.

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

Конфигурация протокола управления качеством

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

Магическое число

Представьте ситуацию, когда ваша программа-клиент шлет сообщения серверу, но последний располагается не на удаленном, а на вашем собственном компьютере. Вместо того, чтобы сообщение вышло наружу и пошло по Интернет, а затем вернулось обратно на сервер, модуль РРР организует так называемую “петлю” (loop-back). Соединение-петля позволяет приложениям типа клиент-сервер, находящимся на одном и том же компьютере, взаимодействовать, не передавая никаких данных по сети. Другими словами, программа делает вид, что посылает сетевые данные, а на самом деле просто оставляет их себе. Сетевое программное обеспечение должно уметь выяснить, что канал является петлей, и затем использовать его подобающим образом. Вариант конфигурации магического числа служит для распознавания канала-петли. В общем, магическое число — это уникальное в рамках сеанса число, используемое модулем РРР для распознавания канала-петли, а также некоторых других специальных случаев конфигурации уровня соединения. По умолчанию магическое число не устанавливается, а его полю присваивается значение 0.

Магическое число и его использование подробно рассматривается в документе RFC 1661.

Схема конфигурации магического числа предполагает, что вероятность того, что оба ведущих сеанс связи компьютера выберут одно и то же число, пренебрежимо мала. Как правило, для выбора магического числа запрашивается функция генерации случайных величин. Схема конфигурации выглядит так: когда модуль РРР получает пакет “конфигурация-запрос” с вариантом конфигурации магического числа, он сравнивает его с предыдущим собственным пакетом “конфигурация-запрос”. Если магические числа различны, это значит, что канал-петля отсутствует.

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

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

Конфигурация сжатия данных поля протокола

Мы уже знаем, что РРР позволяет размещать обычно двухбайтовое поле протокола в одном байте. Вариант конфигурации сжатия данных поля протокола (Protocol Field Compression, PFC) позволяет РРР договориться с удаленным модулем о таком сжатии. Послав пакет “конфигурация-запрос” на установление сжатия данных поля протокола и получив положительный ответ, то есть пакет “конфигурация-подтверждено”, оба модуля продолжают сеанс, размещая поле протокола в одном байте вместо двух. Однако любая реализация РРР обязана уметь работать и без такого сжатия, то есть используя нормальное двухбайтовое поле. Протокол РРР никогда не сжимает поле протокола в пакетах LCP. Пакеты LCP всегда имеют двухбайтовое поле протокола. Это необходимо, так как на стадии обмена пакетами LCP один модуль РРР может еще не знать, выбран ли тот или иной метод сжатия его партнером. Имейте также в виду, что, подсчитывая контрольную сумму CRC пакета и сжимая данные в поле протокола, модуль РРР исходит из того, что кадр РРР тоже сжат.

Конфигурация сжатия полей адреса и управления

Поскольку поля адреса и управления сетевого уровня соединения суть постоянные величины, они — первые кандидаты на удаление из кадра РРР. Вариант конфигурации сжатия полей адреса и управления (ACFC) позволяет модулю РРР договориться с партнером об удалении этой лишней информации из кадров последующего сеанса связи. Удаление дает выигрыш в размере двух байтов на кадр, увеличивая, таким образом, производительность сеанса. Так же, как и в случае конфигурации сжатия поля протокола, сжатие полей адреса и управления в пакетах LCP невозможно. Таким образом, формат пакетов LCP всегда остается однозначным. Также для подсчета контрольной суммы CRC модуль РРР использует размер сжатого кадра.