2. Протокол управления каналом LCP (Link Control Protocol), позволяющий устанавливать соединения, тестировать их, договариваться о параметрах использования и снова отключать их, когда они не нужны.

3. Способ договориться о параметрах сетевого уровня независимо от используемого в нем протокола. Данный метод состоит в том, что для каждого поддерживаемого сетевого уровня имеется свой сетевой протокол управления NCP (Network Control Protocol).

Чтобы не изобретать велосипед, для PPP был выбран формат фрейма, близкий к формату высокоуровневого протокола управления каналом HDLC (High-level Data Link Control), некогда популярного представителя раннего семейства протоколов.

В отличие от бит-ориентированного протокола HDLC, PPP является байт-ориентированным. В частности, в PPP применяется байт-стаффинг, поэтому все фреймы состоят из целого числа байтов. HDLC использует бит-стаффинг; это позволяет отправить фрейм размером, к примеру, 30,25 байта.

Существует второе важное отличие. HDLC предоставляет надежную передачу за счет метода «раздвижного окна», подтверждений и тайм-аутов, как мы видели выше. PPP также может обеспечить надежность в зашумленной среде, например в беспроводных сетях; детали определены в стандарте RFC 1663. Однако на практике это применяется редко. Вместо этого для предоставления службы без установки соединения и без подтверждений в интернете применяется ненумерованный режим.

Формат фрейма PPP показан на илл. 3.24. Все PPP-фреймы начинаются со стандартного флагового байта протокола HDLC 0x7E (01111110). Если этот байт встречается в поле Payload, он предваряется управляющим байтом 0x7D, а следующий за ним представляет собой экранированный байт, сложенный по модулю 2 со значением 0x20 (при этом переключается пятый бит). Например, 0x7D 0x5E — это управляющая последовательность для флагового байта 0x7E. Это означает, что начало и конец фрейма можно найти, просто просканировав содержимое на наличие байта 0x7E. Больше он нигде встречаться не будет. Правило удаления заполняющих битов при получении — найти значение 0x7D, удалить его, а следующий байт сложить по модулю 2 со значением 0x20. Кроме того, между фреймами необходим только один флаговый байт. Несколько флаговых байтов могут применяться для заполнения канала при отсутствии фреймов данных для отправки получателю.

Илл. 3.24. Полный формат фрейма PPP для работы в ненумерованном режиме

После стартового фрейма идет поле Address (Адрес), которому всегда присваивается двоичное значение 11111111; это означает, что все станции должны принимать этот фрейм. Использование такого значения позволяет избежать необходимости назначать адреса передачи данных.

За полем адреса следует поле Control (Управляющее поле), его значение по умолчанию равно 00000011. Это число означает ненумерованный фрейм.

Так как по умолчанию поля Address и Control являются константами, протокол LCP позволяет двум сторонам договориться о возможности пропустить оба поля и сэкономить таким образом по 2 байта на фрейм.

Четвертое поле фрейма PPP — Protocol (Протокол). Оно определяет тип пакета, который содержится в поле Payload. Номера, начинающиеся с бита 0, отведены для IP версий 4 и 6, а также других протоколов сетевого уровня, таких как IPX и AppleTalk. С бита 1 начинаются коды, используемые в конфигурационных протоколах PPP, включая LCP и различные NCP для каждого поддерживаемого протокола сетевого уровня. Размер поля Protocol по умолчанию составляет 2 байта, однако путем переговоров с помощью LCP он может быть уменьшен до одного байта. Вероятно, разработчики перестраховались на случай, если когда-либо будет использоваться более 256 протоколов.

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

Следом за Payload располагается поле Checksum (Контрольная сумма). В обычном состоянии оно занимает 2 байта, но в случае необходимости по договоренности может занимать четыре. Четырехбайтная контрольная сумма фактически представляет собой 32-битный код CRC, образующий многочлен которого представлен в конце раздела 3.2.2. Двухбайтная контрольная сумма также является стандартным кодом CRC.

Итак, PPP — это механизм формирования фреймов, работающий со многими протоколами в разных физических средах. Варианты использования PPP в сетях SONET описаны в стандарте RFC 2615 (см. Малис и Симпсон; Malis and Simpson, 1999). Применяется четырехбайтная контрольная сумма, так как она считается основным способом распознавания ошибок передачи на физическом, канальном и сетевом уровнях. Рекомендуется не сжимать поля Address, Control и Protocol, так как каналы SONET и так работают на относительно высокой скорости.

Есть и еще одна интересная особенность. Перед тем как попасть в поток данных SONET, полезная информация протокола PPP скремблируется (как описано в разделе 2.4.3). При скремблировании данные складываются по модулю 2 с длинной псевдослучайной последовательностью. Только после этого они пересылаются получателю. Проблема в том, что потоку данных SONET для успешной синхронизации требуется частая смена значений битов. В колебаниях голосового сигнала это происходит естественным образом, но при пересылке данных пользователь сам выбирает, какую информацию передать. Он может, к примеру, отправить длинную последовательность нулей и вызвать тем самым проблемы. Благодаря скремблированию вероятность такого развития событий ничтожно мала.