Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Мир TCP/IP.Протоколы для последовательных линий связи

В. Л. Гуторов

Семейство протоколов TCP/IP работает во множестве сетевых сред: в ЛВС Ethernet и Token Ring, на спутниковых каналах и последовательных линиях связи. Для большинства физических сред передачи данных и каналообразующего оборудования существуют спецификации пакетной передачи информации. Так, для использования последовательных линий в качестве каналов в сетях IP были разработаны протоколы SLIP и PPP, описанные в данной статье1.

Протокол SLIP

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

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

Технические особенности

Для того чтобы распознать границы пакетов IP2, передаваемых по последовательной линии связи, и отделить один пакет от другого, протокол SLIP предусматривает использование специального символа END, значение которого в шестнадцатеричном представлении3 равно C0. Применение специального символа может породить конфликт: если байт пересылаемых данных тождественен символу END, то он будет ошибочно определен как признак конца пакета. Чтобы предотвратить такую ситуацию, байт данных со значением, равным значению символа END, заменяется составной двухбайтовой последовательностью, состоящей из специального символа ESC (DB) и кода DC. (Применяемый в протоколе SLIP символ ESC, не равный символу ESC в кодировке ASCII, будем обозначать SLIP ESC.) Если же байт данных имеет тот же код, что и символ SLIP ESC, то он заменяется двухбайтовой последовательностью, состоящей из собственно символа SLIP ESC и кода DD. После последнего байта пакета передается символ END.

Механизм формирования составных последовательностей показан на рис.1. Здесь приведены стандартный пакет IP, один байт которого тождественен символу END, а другой — символу SLIP ESC, и соответствующий ему пакет SLIP, который больше на 4 байта.

Хотя в спецификации протокола SLIP не определена максимальная длина передаваемого пакета, реальный размер пакета IP не должен превышать 1006 байтов. Данное ограничение связано с первой реализацией протокола SLIP в соответствующем драйвере для Berkley Unix, и его соблюдение необходимо для поддержки совместимости разных реализаций SLIP.

Ограничения

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

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

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

Compressed SLIP

Низкая пропускная способность последовательных линий связи вынуждает сокращать время передачи пакетов, уменьшая объем содержащейся в них служебной информации. Эта задача решается с помощью протокола Compressed SLIP (CSLIP), поддерживающего сжатие заголовков пакетов. Появление CSLIP объясняется тем фактом, что при использовании программ типа Telnet, Rlogin и других для пересылки одного байта данных требуется переслать 20-байтовый заголовок пакета IP и 20-байтовый заголовок пакета TCP (итого 40 байтов). Спецификация CSLIP обеспечивает сжатие 40-байтового заголовка до 3—5 байтов. На сегодняшний момент большинство реализаций протокола SLIP поддерживают спецификацию CSLIP.

Таким образом, протокол SLIP выделяет последовательность байтов, формирующих пакет IP, и ничего более. Он не имеет механизмов передачи адресной информации, идентификации типа протокола сетевого уровня, определения и коррекции ошибок. Но он очень прост, что обеспечивает легкость его реализации.

Протокол PPP

Протокол PPP был разработан Инженерной проблемной группой Internet и пришел на смену фактически устаревшему протоколу SLIP.

Технические особенности

В отличие от SLIP протокол PPP может работать не только с интерфейсом RS232, но и с другими интерфейсами между оконечным оборудованием данных (ООД) и аппаратурой передачи данных (АПД). А именно с RS422, RS423 и V.35. Протокол PPP достаточно неприхотлив и может работать без управляющих сигналов модемов (таких, как Request to Send, Clear to Send, Data Carrier Detect, Data Terminal Ready). Единственное жесткое требование, предъявляемое PPP к линии связи, — обеспечение дуплексного соединения, которое может работать в асинхронном (стартстопном) или синхронном режиме.

Протокол PPP состоит из трех частей:

· механизма инкапсуляции пакетов протоколов сетевого уровня для их передачи по последовательной линии связи;

· протокола Link Control Protocol (LCP) для установления, конфигурирования и тестирования соединения;

· семейства протоколов Network Control Protocols (NCP) для установления и конфигурирования процесса передачи трафика различных сетевых протоколов.

Формат кадра протокола PPP (рис.2) был выбран аналогичным формату кадра протокола HDLC (High Level Data Link Control). Каждый кадр PPP начинается и заканчивается байтом-флагом (flag) со значением 7E. Затем следует поле Address со значением, всегда равным FF, и поле Control со значением 03. Дальше находится двухбайтовое поле Protocol, значение которого определяется типом пакета, содержащегося в поле Information (табл.). За полем Information следует поле контрольной суммы (Cyclic Redundancy Code — CRC).

Если при синхронном типе связи в поле Information появляется байт со значением 7E (значение байта-флага), то ситуация обрабатывается на аппаратном уровне с помощью техники вставки битов (bit stuffing).

При асинхронном (стартстопном) типе связи ситуации, когда между байтами-флагами появляются байты со значениями 7E, 7D (значение символа ESC — escape) и значениями меньшими 20 (значения управляющих символов ASCII), обрабатываются при помощи составных последовательностей. Байт 7E передается как двухбайтовая последовательность 7D, 5E; байт 7D — как последовательность 7D, 5D; байты XX со значениями меньшими 20 — как XX, 01.

Алгоритм работы

Рассмотрим процесс работы протокола PPP (рис. 3). Фаза Dead начинает и заканчивает процесс связи. В случае появления внешнего события (например, готовность аппаратного обеспечения осуществить связь) будет инициирована фаза Establish, в которой происходит согласование различных параметров соединения (обмен пакетами LCP). В случае невозможности согласовать некоторый параметр процесс прервется и протокол перейдет в состояние Dead. Если же все необходимые параметры согласованы, будет инициирована фаза Authenticate, в которой проводится проверка на подлинность участников сеанса связи (если таковая требуется). В случае неудачной аутентификации будет инициирована фаза Terminate, подготавливающая разрыв соединения. Если же фаза Authenticate прошла успешно, протокол переходит к фазе Network. В этой фазе осуществляется пересылка данных в соответствии с ранее сконфигурированными параметрами связи (в частности типом сетевого протокола)4. Фаза Terminate (используется по окончании передачи кадров или в случае возникновения каких-либо ошибок) прерывает передачу кадров и переводит протокол PPP в состояние Dead. Необходимо уточнить, что для более ясного понимания описанный процесс работы протокола сильно упрощен.

Преимущества

В общем и целом по сравнению с протоколом SLIP протокол PPP является значительно более развитым инструментом для работы на последовательных линиях и имеет следующие преимущества:

· возможность одновременной работы по различным сетевым протоколам, а не только по IP;

· проверка целостности данных путем подсчета контрольной суммы;

· поддержка динамического обмена адресами IP;

· возможность сжатия заголовков пакетов IP и TCP с помощью алгоритмов, разработанных Ван Якобсоном (Van Jacobson); механизм похож на реализованный в протоколе CSLIP.

Перспективы

Тестовые испытания, проведенные недавно в фирме Morning Star Technologies, показали, что существенной разницы в производительности протоколов SLIP и PPP нет. Различие приемо-передающих характеристик компьютеров, модемов и даже качество реализации протоколов влияет на производительность гораздо больше, чем собственно различия между протоколами.

До недавнего времени пользователей протокола SLIP было больше, чем пользователей протокола PPP, но в основном это было связано с малым числом программных продуктов, реализующих PPP. Однако сейчас не вызывает сомнений, что будущее — за протоколом PPP. Это подтверждается массовым появлением продуктов, поддерживающих данный протокол (см., например, статью Брюса Бордмана “Удаленный доступ по PPP” — “Сети и системы связи”, 1/96, с.28). Кроме того, время не стоит на месте, среди последних новостей — реализация спецификации Point-to-Point Tunneling Protocol, разработанной фирмой US Robotics совместно с Microsoft.




  

 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх