Сетевой межузловой протокол PPP - история возникновения, область применения, основные команды, перспективы

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

Три класса LCP-пакетов

Существует  три класса 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 показан на рис. 4. 

     Рис. 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-битовые поля код. Значения этих кодов приведены в таблице 2.

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

     Для случая запроса 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)

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

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

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

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

• Никакого асинхронного управления кодированием символов
• Запрет использования магических чисел
• Запрещено мониторирование качества канала
• Сжатие полей адреса, протокола и управления
• Никаких составных кадров
• Запрет заполнения с самоописанием (Self-Describing-Padding)

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

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

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

Протоколы SLIP и CSLIP 

     Первым  стандартом де-факто, позволяющим устройствам, соединенным последовательной линией связи, работать по протоколам TCP/IP , был протокол SLIP (Serial Line IP ), созданный в начале 80-х годов и в 1984 году встроенный Риком Адамсом (Rick Adams) в ОС 4.2 Berkley UNIX. Позднее SLIP был поддержан и в других версиях UNIX и реализован в программном обеспечении для ПК.

     Популярность  протокола SLIP объясняется тем, что  он дал возможность подключаться к сети Internet посредством стандартного порта RS232, имеющегося в большинстве  компьютеров. В настоящее время SLIP широко используется в основном на домашних компьютерах, подключенных к последовательным линиям, которые имеют пропускную способность от 1200 бит/с до 19,2 Кбит/с.

     Ограничения

     Для установления связи по протоколу SLIP в стеке протоколов TCP/IP компьютеры должны иметь информацию об адресах IP друг друга. Однако возможна ситуация, когда, скажем, при осуществлении соединения между хостом и маршрутизатором последнему понадобится передать хосту информацию о его адресе IP. Но в протоколе SLIP нет механизмов, дающих возможность обмениваться адресной информацией. Это ограничение не позволяет использовать SLIP для некоторых видов сетевого сервиса. Например, каждый раз после установления SLIP -соединения компьютер превращается в полноправный хост Internet со своим собственным IP -адресом. Если провайдер использует динамическое присвоение IP -адресов, то при каждом новом соединении компьютер будет получать новый IP адрес. Следовательно, другие компьютеры в сети будут вынуждены искать его под неизвестно каким адресом.

     Другой  недостаток SLIP - отсутствие индикации типа протокола, пакет которого инкапсулируется в пакет SLIP. Поэтому через последовательную линию по протоколу SLIP можно передавать трафик лишь одного сетевого протокола.

     При работе с реальными телефонными  линиями, зашумленными и поэтому искажающими пересылаемые данные, требуются процедуры обнаружения и коррекции ошибок. В протоколе SLIP такие процедуры не предусмотрены. Эти функции обеспечивают:

• Либо вышележащие протоколы, например, в стеке TCP/IP протокол IP проводит тестирование целостности пакета по заголовку IP, а один из двух транспортных протоколов (UDP или TCP) проверяет целостность всех данных по контрольным суммам. Однако в протоколе UDP не обязательно использование контрольных сумм, поэтому совместное использование UDP и SLIP нежелательно.
• Либо нижележащие протоколы. Поскольку для установления соединения по протоколу SLIP обычно используется модем, работающий по телефонной линии и подключенный к асинхронному, последовательному порту. Два компьютера, установившие такое соединение, обмениваются данными с паузами переменной длины. К сожалению, в телефонной линии всегда присутствуют помехи, иначе называемые шумом, поэтому модемы, подключаемые к телефонной сети, отличают данные от возможных помех, пользуясь различными параметрами связи. При использовании модема и программного обеспечения для обмена данными настраиваются определенные параметры связи, такие как скорость, размер данных, контроль четности. Для успешного взаимодействия двух модемов оба они должны быть одинаково настроены.

     Но, несмотря на это, для повышения эффективности  работы протоколу SLIP не помешало бы иметь  собственный механизм (пусть даже простейший) коррекции ошибок.

     Отсутствие  этих возможностей делает протокол SLIP очень простым в реализации и, следовательно, популярным.

     Compressed SLIP

     Низкая  пропускная способность последовательных линий вынуждает сокращать время  передачи пакетов, уменьшая объем содержащейся в них служебной информации. Эта  задача решается с помощью протокола Compressed SLIP , поддерживающего сжатие заголовков пакетов. Этот протокол был создан в Lawrence Berkeley Labs (LBL) Ван Якобсоном, как способ повысить эффективность последовательной передачи и уровень сервиса прикладных программ, использующих TCP/IP на медленных линиях. Появление CSLIP объясняется тем, что при использовании программ типа telnet, rlogin и других для пересылки одного байта данных требуется переслать 20-байтовый заголовок пакета IP и 20-байтовый заголовок пакета TCP . Спецификация CSLIP обеспечивает сжатие 40 байтов заголовка до 3-5 байтов.

     На  низких скоростях передачи данных эта  разница заметна только при работе с пакетами, несущими малые объёмы информации, такие пакеты порождаются, например, при работе telnet или rlogin. На больших же скоростях CSLIP даёт меньший выигрыш и почти ничего не даёт для пакетов с большими объёмами данных, например, ftp -пакетов.

     CSLIP для пересылки пакета использует  информацию из предыдущего пакета, т.е. передача имеет структуру  цепочки. Первый пакет в цепочке  - несжатый. Если какой-либо пакет теряется, то цепочка рвётся, нельзя этот же пакет запросить в самом конце, его нужно пересылать заново тут же, т.е. прекращать процесс передачи и начинать новую цепочку. Таким образом, эта технология при частых пропажах или искажениях пакетов приводит к большим потерям времени, чем обычный SLIP . Это происходит из-за задержек на остановку и передачу нового несжатого пакета.

     Одной из причин малого числа  каналов связи IP с непосредственным соединением было отсутствие стандартного протокола формирования пакета данных Internet. Протокол PPP предназначался для решения этой проблемы. Помимо решения проблемы формирования стандартных пакетов данных Internet IP в каналах с непосредственным соединением, РРР также должен был решить другие проблемы, в том числе присвоение и управление адресами IP, асинхронное (старт/стоп) и синхронное бит-ориентированное формирование пакета данных, мультиплексирование протокола сети, конфигурация канала связи, проверка качества канала связи, обнаружение ошибок и согласование варианта для таких способностей, как согласование адреса сетевого уровня и согласование компрессии информации. РРР решает эти вопросы путем обеспечения расширяемого протокола управления каналом (LCP) и семейства протоколов управления сетью (NCP) , которые позволяют согласовывать факультативные параметры конфигурации и различные возможности. Сегодня PPP , помимо IP , обеспечивает также и другие протоколы, в том числе IPX и DECnet .