3.5. Протокол PPP

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

Протокол PPP (Point-to-Point Protocol; RFC-2716, -2701, -2688, -2687, -2686, -2615, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -1993, -1990, -1989, -1979, -1978, -1977, -1976, -1975, -1974, -1973, -1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552, -1378, -1377, -1334, -1332, -1331, и STD-51, cмотри также www.spitbrook.destek.com:81/pptp.txt) предназначен для решения тех же задач, что и SLIP, но лишен многих его недостатков, он служит для передачи мультипротокольных дейтограмм от одного узла к другому. Сам по себе список RFC, приведенный выше, впечатляющ. Он говорит о том, что данный протокол относится к числу наиболее важных и широко используемых. Это и понятно, большинство региональных сетей строится с использованием соединений точка-точка. PPP поддерживает, как асинхронный режим с 8 битами данных без бита четности (согласуется со свойствами последовательного интерфейса, имеющегося практически на всех ЭВМ), так и побитовый синхронный режим. Протокол содержит в себе три составные части:

• Метод инкапсуляции дейтограмм при передаче по последовательным коммуникационным каналам.

• Протокол LCP для установления, конфигурирования и тестирования информационных каналов

• Набор протоколов NCP для установки и конфигурирования различных протоколов сетевого уровня.

Протокол управления каналом (LCP - Link Control Protocol) является частью PPP. Идеология NCP реализована и в протоколе TCP. Каждый кадр PPP начинается и завершается флагом 0x7E. За стартовым флагом-октетом следует байт адреса, который всегда равен 0xFF. Формат кадра PPP представлен на рисунке 3.5.1. Кадр ppp может содержать только целое число байт. При инкапсуляции других пакетов в PPP используется бит-ориентированный протокол HDLC (High-level Data Link Control).

Рис. 3.5.1 Формат кадра в протоколе PPP

Поле адрес всегда содержит байт 0xff (смотри также HDLC). Это указывает на то, что все станции должны принять этот кадр, и исключает необходимость выделения каких-то специальных адресов. Байт управления всегда равен 0x03, что указывает на ненумерованный тип кадра. По умолчанию кадры PPP передаются в режиме "без установления соединения". Если требуется надежная доставка, используется версия, описанная в RFC-1663. Двухоктетное поле протокол сходно по функции с полем тип в кадре Ethernet и определяет то, как следует интерпретировать информационное поле (см. табл. 3.5.1). Значение 0x0021 этого поля говорит о том, что последующее информационное поле содержит в себе IP-дейтограмму. Поле CRC (Cyclic Redundancy Check) представляет собой циклическую контрольную сумму, предназначенную для выявления ошибок при транспортировке PPP-кадра. Применение флагов-ограничителей кадра (0x7E) создает те же проблемы, о которых говорилось при описании SLIP-протокола, - эти байты не могут присутствовать в информационном поле. В синхронном режиме эта проблема решается на аппаратном уровне. При работе в асинхронном режиме для этого используется специальный ESC-символ, равный 0x7D. Когда этот esc-символ встречается в информационном поле, шестой бит в следующем за ним байте инвертируется. Так байт 0x7E будет преобразован в последовательность 0x7D, 0x5E, а байт 0x7D - в два байта 0x7D, 0x5D. Все символы с кодами меньше 0x20 также преобразуются в ESC-последовательности. Например, 0x07 будет преобразован в 0x7D, 0x27. Это необходимо делать, так как управляющие символы могут оказать непредсказуемые воздействия на режим работы драйверов или модемов, используемых в канале. Протокол ppp в отличие от SLIP допускает мультипротокольность и динамическое определение IP-адресов партнеров. Несмотря на определенные преимущества протокола PPP перед SLIP, последний распространен достаточно широко. Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации.

Таблица 3.5.1. Стандартизованные DLL-номера протоколов для PPP (поле протокол)

DLL-код протокола (шестнадцатеричный)	Наименование протокола
0001	Протокол заполнения (padding)
0003-001F	Зарезервировано
0021	IP-протокол
0023	Сетевой уровень OSI
0025	Xerox NS IDP
0027	Decnet фаза IV
0029	Appletalk
002B	Novell IPX
002D	Компрессированный TCP/IP протокол Ван Джекобсона
002F	Не компрессированный TCP/IP протокол Ван Джекобсона
0031	PDU мостов
0033	Потоковый протокол (ST-II)
0035	Banyan Vines
0039	Appletalk EDDP
003B	Appletalk Smartbuffered
003D	Multi-link
003F	Кадры Netbios
0041	Cisco Systems
0043	Ascom Timeplex
0047	Удаленная локальная сеть DCA
0049	Транспортный протокол для последовательных данных (PPP-SDTP)
004B	SNA через 802.2
004D	SNA
004F	Сжатие заголовков IPv6
007D	Зарезервировано (Управл. ESC) [RFC1661]
00FD	1-ый вариант компрессии
0201	Пакеты отклика 802.1d
0203	IBM BPDU базовой маршрутизации
8021	Управляющий протокол Интернет (IPCP)
8023	Управляющий протокол сетевого уровня OSI
8025	Управляющий протокол Xerox NS IDP
8027	Управляющий протокол Decnet фаза VI
8029	Управляющий протокол Appletalk
802B	Управляющий протокол Novell IPX
8031	Бридж NCP
8033	Потоковый управляющий протокол
8035	Управляющий протокол Banyan Vines
803D	Многосвязный управляющий протокол
803F	Управляющий протокол кадров NetBIOS
8041	Управляющий протокол Cisco
8043	Ascom Timeplex
8045	Управляющий протокол Fujitsu LBLB
8047	Управляющий протокол удаленных локальных сетей DCA (RLNCP)
8049	Управляющий протокол передачи последовательных данных (PPP-SDCP)
804B	Управляющий протокол для передачи sna поверх 802.2
804D	Управляющий протокол SNA
804F	Управляющий протокол сжатия заголовков IPv6
80FD	Управляющий протокол сжатия
C021	Канальный управляющий протокол
C023	Протокол аутентификации паролей
C025	Сообщение о состоянии канала
C081	Управляющий протокол для работы с контейнерами

Значения кодов поля протокола от 0xxx до 3xxx идентифицируют протоколы сетевого уровня, а значения в интервале 8xxx - bxxx говорят о том, что протокол соответствует NCP (Network Control Protocol). Коды из диапазона 4xxx - 7xxx используются для протоколов с низким уровнем трафика, а коды от cxxx до exxx соответствуют управляющим протоколам (например, LCP).

Протокол PPP при установлении соединения предусматривает процедуру аутентификации, которая является опционной (смотри рис. 3.5.2.). После перехода на сетевой уровень вызывается NCP-протокол, который выполняет необходимую конфигурацию канала.

Рис. 3.5.2. Алгоритм установления соединения PPP

При обнаружении несущей или по инициативе клиента система может попытаться установить соединение. В случае успеха система переходит в фазу аутентификации. Если же и фаза аутентификации завершается благополучно, система выполняет подключение к сети (IP, IPX, Appletalk и т.д.), настройка сетевого уровня производится в рамках протокола NCP. Во всех остальных случаях производится возврат в исходное состояние. Процедура закрытия соединения осуществляется протоколом LCP.

В поле данных PPP-пакета может быть вложен один LCP-пакет, в этом случае в поле протокол должен быть записан код 0xC021 (Link Control Protocol). LCP-протокол служит для установления соединения путем обмена конфигурационными пакетами. По завершении этого обмена система переходит в фазу аутентификации (рис.3.5.2). Формат LCP-пакета показан на рис. 3.5.3.

Рис. 3.5.3. Формат заголовка LCP-пакета

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

В качестве примера можно рассмотреть процедуру подключения персональной ЭВМ к серверу через модем. После того как модем маршрутизатора ответит на вызов модема-клиента и установит физическое соединение, ЭВМ посылает последовательность LCP-пакетов, вложенных в поля данных одного или нескольких PPP-кадров. Это позволяет выбрать необходимые параметры PPP. По завершении этой процедуры посылается последовательность NCP-пакетов, которые конфигурируют сетевой уровень. Вероятно, ЭВМ захочет работать со стеком протоколов TCP/IP, и по этой причине нуждается в IP-адресе. Если провайдер имеет N IP-адресов в резерве, он может подключить одновременно N ЭВМ. Присвоение IP-адреса осуществляется также в рамках NCP-протокола. После этого ЭВИ становится узлом Интернет. Завершение сессии и освобождение IP-адреса выполняется также через NCP-протокол. Разрыв соединения осуществляет протокол LCP.

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

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

Существует три класса LCP-пакетов:

1. Пакеты конфигурации канала, которые используются при формировании виртуального канала (Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject) .

2. Пакеты закрытия канала (Terminate-Request и Terminate-Ack).

3. Пакеты поддержания, которые служат для управления и отладки(Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).

Аналогом LCP является протокол IPCP (IP Control Protocol). В поле код протокола в этом случае записывается 8021 (RFC-1332). Формат пакета IPCP показан на рис. 3.5.4.

Рис. 3.5.4. Формат пакета IPCP. Младшие биты слева.

Поле тип содержит 2, в поле длина заносится число байт в пакете (≥4). В поле протокол сжатия IP заносится код алгоритма сжатия (0х02D - в случае алгоритма Ван Джекобсона). Поле данные может содержать нуль или более октетов. Конфигурационный запрос может потребовать присылки (присвоения) IP-адреса. Для решения этой задачи предусмотрена опция IPCP-пакета, где поле тип=3, длина=6, а последующие 4 байта выделены для IP-адреса, куда отправитель должен его записать. Если туда записаны нули, это говорит о том, что отправитель запрашивает свой IP-адрес.

Протоколы PPP, LCP (Link Control Protocol), CCP (Compression Control Protocol; RFC-1962, -1967), и некоторые другие управляющие протоколы содержат 8-битовые поля код. Значения этих кодов приведены в таблице 3.5.2.

Таблица 3.5.2 Значения поля код LCP-заголовка

Код	Тип пакета
1	Запрос конфигурации	Configure-Request
2	Подтверждение конфигурации	Configure-Ack
3	Не подтверждение конфигурации	Configure-Nak
4	Отклонение конфигурации	Configure-Reject
5	Запрос завершения	Terminate-Request
6	Подтверждение завершения	Terminate-Ack
7	Отклонение кода	Code-Reject
8*	Отклонение протокола	Protocol-Reject
9*	Запрос отклика	Echo-Request
10*	Эхо-отклик	Echo-Reply
11*	Запрос отмены	Discard-Request
12*	Идентификация
13*	Остающееся время
14**	Запрос сброса
15**	Отклик на запрос сброса
*) Только LCP;	**) Только CCP

Для случая запроса Discard-Request между полями длина и данные помещается 4-байтовое поле Magic-Number (магическое число).

Протокол PPP многолик, он способен поддерживать и многоканальные соединения (RFC-1990). Это бывает полезно при работе через ISDN, X.25, Frame Relay или при необходимости расширить пропускную способность за счет подключения нескольких параллельных каналов (MP - MultiLink Protocol). Так как я не сталкивался со случаями, когда пропускной способности было вполне достаточно, данную модификацию PPP-протокола следует считать крайне важной. При этом одной из проблем является распределение пакетов по каналам и последующее их упорядочение принимающей стороной. Особую осторожность в этом случае следует соблюдать при использовании заполнителей. В этом режиме по виртуальному каналу MultiLink запрещается посылать конфигурационные LCP-пакеты Configure-Request, -Reject, -Ack, -Nak, Terminate-Request или -Ack. Принимающая сторона в случае их обнаружения должна их игнорировать. Применение других LCP-пакетов допускается (например, Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).

Формат MP-пакета представлен на рис. 3.5.5.

Рис. 3.5.5. Формат MР-пакета

Поля PID - идентификатор протокола. Субполе B (Beginning) - бит фрагмента =1 для первого фрагмента PPP и =0 для всех последующих фрагментов. Субполе E (Ending) - бит фрагмента =1 для последнего фрагмента PPP и =0 для всех прочих фрагментов. Поле номер по порядку имеет длину 24 бита. Существует модификация пакета с укороченным кодом (12 бит) номера по порядку. При этом к этому полю отходят 4 нулевые бита после BE00. Выбор длины этого поля осуществляется протоколом LCP. Значение полу увеличивается на 1 при посылке очередного фрагмента. Для вышерасположенных уровней совокупность совместно используемых каналов выглядит, как один виртуальный канал.

При передаче пакетов по каналу Multilink инкапсуляция производится согласно следующим правилам, которые задаются вручную:

• Никакого асинхронного управления кодированием символов

• Запрет использования магических чисел

• Запрещено мониторирование качества канала

• Сжатие полей адреса, протокола и управления

• Никаких составных кадров

• Запрет заполнения с самоописанием (Self-Describing-Padding)

Для предварительно фрагментированных пакетов запрещено дополнение нулями или использование каких-либо иных заполнителей. Рассмотрим пример Multilink-соединения, приведенный на рис. 3.5.6. Канал 1 между двумя системами согласуется сетевыми уровнями NL1, NL2 и MP. Затем эти две системы согласуют с MP канал 2. Кадры, полученные каналом 1, демультиплексируются на канальном уровне согласно сетевому протокольному идентификатору PPP и могут быть посланы NL1, NL2 или MP. Канал 2 примет кадры со всеми сетевыми протокольными идентификаторами, с которыми принимает их канал 1. Кадры, полученные MP, позднее демультиплексируются на сетевом уровне согласно протокольному идентификатору PPP и посылаются NL1 или NL2. Любые кадры, полученные MP для других протоколов сетевого уровня, отбрасываются с помощью стандартного протокольного механизма (Reject).

Рис. 3.5.6. Пример Multilink-конфигурации

Так как межсетевые связи часто используют последовательные каналы (выделенные линии, радиомодемы и пр.), протокол PPP распространен достаточно широко. Протокол PPP служит и для создания межсетевых туннелей (протокол PPTP - Point to Point Tunneling Protocol). Протокол PPTP использует MTU=1532, номер порта 5678 и номер версии 0x0100, пакеты данных здесь транспортируются с использованием протокола инкапсуляции GRE V2 (см. сноску в начале раздела).

Назад: 3.4. Протокол SLIP
Оглавление: Телекоммуникационные технологии
Вперёд: 3.6. Протокол G.703