Протокол РРР

Формат кадра HDLC состоит из пяти отдельных полей, в которые инкапсулируются данные протокола РРР, посылаемые по модемной линии.

Поле Флаг используется для идентификации начала кадра HDLC. Определено, что в него заносится двоичное значение 01111110 или, в шестнадцатеричном выражении, 0x7e. При этом программное обеспечение HDLC должно обнаружить это поле и опознать значение как начало нового кадра.

В поле Адрес всегда установлена двоичная величина 11111111 или 0xff в шестнадцатеричном выражении. Это широковещательный адрес. Все станции должны уметь опознавать данные, которые направлены на этот адрес. Так как в "сети" HDLC обычно всего два устройства, то очевидно, какому устройству предназначены данные с широковещательным адресом.

Для РРР-пакетов в поле Управление в HDLC всегда установлено двоичное значение 00000011 (шестнадцатеричное 0x03 ). Приемной стороной должны отвергаться кадры с другими значениями в этом поле.

Так как поля управления и адреса всегда содержат одни и те же значения, то с целью экономии полосы пропускания они часто опускаются. Таким образом, первое значение после поля флага может восприниматься либо как начало пакета РРР, либо как поле Протокол (см. описание кадра РРР). Именно поэтому в поле Протокол кадра РРР не могут использоваться величины 0xff и 0x03, так как это может ввести в заблуждение принимающую сторону, которая может "решить", что получает поля адреса и управления HDLC. Сокращение полей HDLC при передаче называется сжатием кадра.

Поле проверочной последовательности кадра FCS (Frame Check Sequence) используется для обнаружения ошибок во время передачи кадра. Значение FCS вычисляется с помощью полей Адрес, Управление и данных из пакета HDLC. При вычислении проверочной последовательности кадра не учитывается поле Флаг, а также старт- и стоп-биты, которые используются в большинстве модемов.

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

Иногда данные РРР имеют те же значения, что и поле флага в HDLC. Это может привести к путанице, так как приемник понимает появление такой последовательности как конец передачи. Чтобы исключить такую возможность, используется так называемая прозрачная передача кадров. После вычисления FCS передатчик проверяет поля между двумя полями флага и вставляет специальный контрольный октет (Control-Escape octet) 01111101 или шестнадцатеричное 0x7d перед каждым значением данных, которое соответствует значению флага. Затем передатчик выполняет логическую операцию "Исключающее ИЛИ" над данными с величиной 0x20, чтобы полученная величина не равнялась значению в поле Флаг. Конечно, если значение данных равно значению контрольного октета, то перед ним также должен быть помещен еще один контрольный октет с последующим выполнением операции "Исключающее ИЛИ" с величиной 0x20. Когда приемник принимает контрольный октет, он уже "знает", что необходимо провести обратное преобразование данных к их нормальному значению.

Удаленный РРР-хост может автоматически определять запрос на установление соединения от удаленного модема путем проверки первой группы октетов, полученных от клиента. Запрос на установку РРР-соединения может быть идентифицирован одной из трех групп октетов, приведенных в листинге 8.1.

1: 7e ff 03 с0 21
2: 7e ff 7d 23 C0 21
3: 7e 7d df 7d 23 c0 21

В строке 1 листинга 8.1 показан стандартный кадр HDLC ( 7e ff 03 ) со стандартным полем протокола LCP ( с0 21 ). В строках 2 и 3 представлены методы создания прозрачности кадров, после которых передаются те же кадры. Принимая любую из этих трех последовательностей по модемной линии, сервер под управлением ОС Linux делает вывод о том, что предпринимается попытка установления РРР-соединения, и реагирует на нее. Программа mgetty+sendfax использует этот механизм для автоматической инициализации сеанса РРР по входящему звонку на стандартной телефонной линии. Если ни одна из трех последовательностей кадров не принята, то сервер под управлением ОС Linux делает вывод, что поступающие данные не являются запросом на организацию сеанса РРР. В роли таких данных могут выступать попытки пользователя ввести свое имя или пароль в обычном терминальном сеансе по модемному или факс-соединению. Как видите, одну и ту же модемную линию можно использовать и в качестве обычного терминала, и для передачи факсов, и для сеансов РРР. При этом для работы со всеми перечисленными службами используется один и тот же телефонный номер.

Кадр РРР

Кадры РРР помещаются в поля данных кадра HDLC. Формат кадра РРР представлен на рисунке 8.2.

Рис. 8.2. Формат кадра РРР

Поле Протокол может иметь длину в один или два октета; оно идентифицирует протокол, который используется в поле Информация. В табл. 8.1 приведены некоторые значения поля Протокол, которые поддерживаются протоколом РРР.

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

Фазы переговоров в протоколе РРР

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