Галкин В.А., Григорьев Ю.А. Телекоммуникации и сети

Подождите немного. Документ загружается.

5. Сетевые

протоколы

ме,

которая обрабатывает

IP-пакеты,

например модулю

TCP.

На обратном пути

SLIP получает от программы (сетевого уровня), посылающей IP-пакеты, IP-

пакет, вычленяет его содержимое, соответствующим образом переформати-

рует, затем делит на символы и отправляет его через устройство последова-

тельной передачи

по

последовательной

линии в сеть

- соседнему

узлу

Internet.

Структура кадра протокола SLIP. Протокол SLIP предназначен для пе-

редачи IP-пакетов через

асинхронные

линии

связи.

Поскольку асинхронная

пе-

редача является байт-ориентирова1шой, то перед транспортировкой средства-

ми SLIP пакет разделяется на октеты (байты), которые передаются один за

другим.

Как известно, в сети Ethernet IP-пакет может иметь длину до 1500 байт, что

обусловливает необходимость его сегментащш - разбиения на более короткие

пакеты. SLIP делает это довольно примитивно. Он не анализирует поток дан-

ных и не

вьщеляет какую-либо информащпо

в этом

потоке.

Для

распознавания

границы

IP-пакетов,

протокол

SLIP

предусматривает использование спещ1аль-

ного символа END, значение которого в шестнадцатеричном представлении

равно

(СО)^.

Для разделе1шя SLIP-кадров между ними вставляется служебный

байт-разделитель - символ ESC (DB)^.

Применение специального символа может породить конфликт: если байт

пересылаемых данных тождественен символу

END,

то он будет ошибочно оп-

ределен как признак конца пакета. Чтобы такой байт, встретившийся внутри

IP-пакета, не воспринимался как разделитель, предусмотрен механизм встав-

ки байта (byte staffing).

Таким образом, собственно служебной информации в протоколе SLIP до-

вольно мало: на IP-пакет добавляется один байт-разделитель (между пакета-

ми они

не

дублируются), а иногда появляется несколько дополнительных бай-

тов,

вставляемых по процедуре вставки байта.

END

СО

со

ESC

Пакет IP

<адр8ЫР

ESC

«л

\ к

, \ END

со

Рис.

5.11.

Соответствие между блоками

данных протоколов IP и SLIP

340

5.4.

Протоколы

IVуровня стека

TCP/IP

Стандарт не определяет фиксированный размер SLIP-кадра, поэтому лю-

бой SLIP-интерфейс имеет специальное поле, в котором пользователь должен

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

SLIP-кадра часто оказьшается ограниченным до очень небольшого значения

(от 256 до 1006 байт). Данное ограничение связано с первой реализацией про-

токола SLIP в соответствующем драйвере для Berkley Unix, и его соблюдение

необходимо

для

поддержки совместимости разных реализаций SLIP (больпшн-

ство современных реализаций поддерживают эту длину

позволяют админис-

тратору самому установить его размер, а по умолчанию принимают размер

1500 байг).

В каждом из SLIP-кадров полностью воспроизводится IP-заголовок разме-

ром 20 байт (рис. 5.11). Из-за этого избыточность, возникающая при передаче

длинньпс пакетов по протоколу SLIP, весьма велика. Существенна и избыточ-

ность, порождаемая самим асинхронным методом передачи

на

интерфейсе ПК-

модем (минимум 20

% на

дополнительные стартовый

стоповый биты

на

каж-

дый байт). Но с этим ничего поделать нельзя, поскольку все персональные

компьютеры имеют только асинхронные порты.

Для установления связи по протоколу SLIP компьютеры должны иметь ин-

формацию об IP-адресах друг друга. В протоколе SLIP нет механизмов, обес-

печивающих возможность обмениваться адресной информацией, так как в

структуре кадра не предусмотрено поле адреса и его специальная обработка.

Поэтому компьютерам, взаимодействующим по протоколу

SLIP,

должны быть

назначены IP-адреса заранее. Каждый раз после установления SLIP-соедине-

ния

компьютер превращается

полноправный хост Internet со своим собствен-

ным ЕР-адресом. Если провайдер использует динамическое присвоение IP-ад-

ресов, то при каждом новом соединении компьютер будет получать новый

IP-адрес. Следовательно, другие компьютеры

сети будут вьшуждены искать

его под неизвестно каким адресом.

Другим недостатком протокола SLIP является отсутствие в нем индикации

типа протокола, пакет которого инкапсулируется в SLIP-кадр. Поэтому через

последовательную линию по протоколу SLBP можно передавать трафик лишь

одного сетевого протокола. SLIP не позволяет различать пакеты по типу про-

токола, например, IP или DECnet. При работе по протоколу SLIP предполага-

ется использование только протокола

IP,

что определено его названием Serial

Line IP

При работе с реальными телефонными линиями, зашумленными и поэтому

искажающими информацию

при

пересылке, необходимы процедуры обнаруже-

ния и коррекции ошибок. В протоколе SLIP такие процедуры не предусмотре-

ны.

Эти функции обеспечивают вышележащие

протоколы:

протокол

прово-

дит тестирование целостности пакета по заголовку IP, а один из двух

транспортных протоколов (UDP или TCP) проверяет целостность всех данных

по контрольным суммам.

341

5. Сетевые

протоколы

В стандартном SLIP не предусмотрено сжатие данных, но существуют его

варианты со сжатием, например С SLIP. Большинство современных модемов,

поддерживающих стандарты V.42bis

MNP5,

осуществляют эту операцию ап-

паратно.

Низкая пропускная способность последовательных линий связи заставляет

сокращать время передачи пакетов, уменьшая объем содержащейся

них слу-

жебной информации. Эта задача решается с помощью протокола Compressed

SLIP (CSLIP), поддерживающего сжатие заголовков IP-пакетов.

Протокол С SLIP бьш создан в Lawrence Berkeley Labs (LBL) Ван Якобсо-

ном как средство повышения эффективности последовательной передачи и

уровня сервиса прикладных программ, использующих TCP/IP на медленных

линиях. Протокол

CSLIP,

по сравнению с протоколом

SLIP,

использует

шесть

раз меньше избыточной информации

(в

виде заголовков). На низких скоростях

передачи данных эта разница заметна только при работе с IP-пакетами, несу-

щими малые объемы информации, такие пакеты формируются, например, при

работе telnet или rlogin. На больших же скоростях CSLIP дает меньший вьшг-

рыш и почти никакого вьшгрыша для пакетов с большими объемами даьшых,

например ftp-пакетов.

Появление

CSLDP

объясняет

тот

факт,

что

при

использовании программ типа

telnet, rlogin

других для пересьшки одного

байта

данных требуется переслать

40 байт служебной информации. При сжатии заголовков 20 октетов заголовка

IP и 20 октетов заголовка TCP (итого 40 байт) заменяются 3-7 октетами.

CSLIP для сжатия - распаковки и проверки правильности пересьшки пакета (и

заголовка) использует информацию из предьщущего пакета, т.е. передача име-

ет структуру цепочки. Первый пакет в цепочке - несжатый. Если какой-либо

пакет теряется, то цепочка рвется, нельзя этот же пакет запросить в самом

конце передачи, его нужно пересьшать заново тут же, т.е. прекращать процесс

передачи

начинать новую цепочку. Таким образом, эта технология

при

пропа-

же или искажении пакетов приводит к большим потерям времени, чем обыч-

ный SLIP. Это происходит из-за задержек на останов и передачу нового несжа-

того пакета.

Так как

протоколе SLIP процедуры обнаружения и коррекции ошибок не

предусмотрены, то нежелательно совместное использование дейтаграммного

протокола UDP и SLIP. Это объясняется тем, что в протоколе UDP не обяза-

тельно применение контрольньпс сумм.

Дальнейшим развитием протокола SLIP является протокол РРР (RFC 1331),

в котором устранены некоторые недостатки протокола SLIP. Необходимо по-

мнить что SLIP и РРР - протоколы канального уровня.

Протокол РРР

Протокол Point-to-Point Protocol (РРР) (протокол канала связи с непосред-

ственным соединением)

бьш

официально опубликован

1993

г.

и стал стандар-

том для связи по последовательным каналам, например таким, которые при-

342

5.4. Протоколы IVуровня стека TCP/IP

меняют для обмена информацией между домашними компьютерами и Internet

по

коммутируемым телефонным

линиям.

РРР имеет значительные преимуще-

ства перед SLIP: компьютеры на противоположных концах соедршения могут

договариваться о параметрах сеанса связи и сообщать друг другу свои IP-

адреса, которые в отличие от SLIP, могут назначаться динамически.

Кроме формирования стандартных IP-пакетов данные, протокол РРР при-

зван решать и другие проблемы, в том числе:

• присвоение

управление ГР-адресами;

• асинхронное и синхронное бит-ориентированное формирование пакета дан-

ных;

• мультиплексирование протокола сети;

• конфигурация канала

связи;

• проверка качества канала связи;

• обнаружение ошибок;

• согласование адреса сетевого уровня;

• согласование протокола

сжатия

информации.

Протокол РРР решает эти задачи путем обеспечения расширяемого прото-

кола управления каналом

(LCP

- Link Control Protocol)

семейства протоколов

управления сетью (NCP - Network Control Protocols), которые позволяют со-

гласовывать факультативные параметры конфигурации и различные возмож-

ности.

РРР реализует метод передачи дейтаграмм через последовательные кана-

лы связи с непосредственным соединением. Протокол РРР содержит три ос-

новные

компонента:

протокол управления каналом передачи данных высокого уровня

(HDLC

используемый в качестве базиса для формирования дейтаграмм при прохож-

дении через каналы с непосредственным соединением;

расширяемый протокол LCP -

для

организации,

выбора конфигурации и

про-

верки соединения канала передачи данных;

семейство протоколов

NCP

для

организации и выбора конфигурации

раз-

личных протоколов

сетевого

уровня.

РРР обеспечивает одновременное пользование множеством протоколов

сетевого уровня.

Основные принципы работы. Чтобы организовать связь через канал

связи

непосредственным соединением, инициирующий РРР сначала отправ-

ляет пакеты LCP для

выбора конфигурации

(факультативно) проверки канала

передачи

данных.

После

того,

как канал установлен и пакетом LCP проведено

необходимое согласование факультативных средств, инициирующий РРР от-

правляет пакеты

NCP,

чтобы выбрать и определить конфигурацию одного или

более протоколов сетевого

уровня.

Как только конфигурация каждого выбран-

ного

протокола определена, дейтаграммы

из

каждого протокола

сетевого

уров-

ня можно отправлять через данный канал. Канал сохраняет свою конфигура-

цию для связи до тех пор, пока явно вьфаженные пакеты LCP или NCP не

343

Сетевые протоколы

закроют

этот канал или пока не

произойдет какое-нибудь внешнее событие (на-

пример,

истечет

срок

бездействия таймера

или

вмешается какой-нибуць пользо-

ватель).

Требования

интерфейсам физического

уровня,

РРР

может работать

через любой интерфейс DTE/DCE (например, EIA RS-232-C, EIA RS-422, EIA

RS-423 и CCITT

V.35).

Единственным требованием, которое предъявляет

РРР,

является

обеспечение дублированных

схем (либо

специально

назначенных,

либо

переключаемых), которые могут

работать

как

синхронном, так

и в

асинхрон-

ном последовательном по битам режиме, прозрачном для блоков данных

ка-

нального уровня

РРР.

Протокол

не

предъявляет каких-либо ограничений, каса-

ющихся скорости передачи информации, кроме

тех,

которые определены

конкретным примененным интерфейсом DTE/DCE.

Канальный

уровень

РРР.

РРР использует

принципы,

терминологию и струк-

туру блока данных процедур

HDLC

(ISO

3309-1979),

модифицированных стан-

дартом ISO 3309-1984/PDADl (Приложение

Стартстопная передача).

ISO

3309-1979 определяет структуру блока данных HLDC для применершя

синх-

ронных режимах передачи. ISO 3309-1984/PDADl определяет предложенные

для стандарта ISO 3309-1979 модификации, которые позволяют его использо-

вание

асинхронных

режимах.

Формат блока данных

РРР

приведен на

рис.

5.12.

Длина поля Flag составляет

байт; она указьгоает на начало или конец бло-

ка данных. Эта последовательность состоит из бинарной последовательности

01111110-(7Е)л.

Длина

поля y4ddress

тоже равна

байт; оно содержит бинарную последова-

тельность

11111111-

(РР)л,

представляющую собой стандартный широковеща-

тельный адрес. РРР не присваивает индивидуальньпс адресов станциям.

Поле Control составляет

байт; содержит информацию

предоставляемых

услугах.

Длина поля Protocol равна 2 байт; его значение идентифицирует протокол,

заключенный

информационном

поле

блока

данных.

Значения

поля

Protocol и

соответствующие им пакеты представлены

табл.

5.6.

Flag

(7Е),

Address

(FF)^

Control

(03)л

Information

PCS

Flag

(7E),

344

Protocol

Oxxx

Cxxx

8xxx

Data

Протокол сетевого уровня

LCP

NCP

Рис.

5.12.

Формат кадра РРР

5.4.

Протоколы IVуровня стека TCP/IP

Таблица

5.6.

Типы пакетов

поля Protocol

Значение поля

Protocol

0021

0023

0025

0027

0029

002В

002D

002F

8021

8023

8025

8027

8029

802В

С021

С023

Тип пакета

ISOCLNP

Xerox NS ГОР

DECnet Phase IV

Apple Talk

IPX

Van Jacobson Compressed ТСРЯР 1

Van Jacobson Compressed TCP/IP 2

IP Control Protocol

ISO CLNP Control Protocol

Xerox NS IDP Control Protocol

DECnet Phase IV Control Protocol

Apple Talk Control Protocol

IPX Control Protocol

Link Control Protocol

User/Password Authentication Protocol

Поле Data содержит дейтаграмму для протокола, заданного

поле протоко-

ла.

Конец информационного поля определяется замьпсающей последователь-

ностью Flag, перед которой размещается два байта поля FCS. Максимальная

длина информационного

поля по

умолчанию равна 1500 байт. В соответствии с

априорным соглашением, разрешающие реализации РРР могут использовать

другие значения максимальной

длины

информационного поля.

Поле проверочной последовательности блока данных FCS (Frame Check

Sequence) обычно составляет 16 бит (2 байт). В соответствии с априорным

соглашением, разрешающие реализации РРР для усиления степени защиты от

ошибок могут использовать 32-битовое (4-байтовое) поле FCS.

Протокол РРР инициируется, используя оба протокола LCP и NCR Для

РРР-соединения определено пять фаз:

• организация канала (Dead Phase). Эта фаза определяет физическую го-

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

таграмм сетевого уровня (например IP). В случае успешной инициализации

физического уровня канал переходит

следующую фазу;

345

5. Сетевые

протоколы

• определение качества канала связи и согласование его конфигурации

(Establish Phase). Эта фаза инициализирует протокол LCP и определяет пара-

метры канала. Здесь проверяется канал, чтобы определить, является ли каче-

ство канала достаточным для вызова протоколов сетевого уровня. Эта фаза

завершается после того, как пакет подтверждения конфигурации (Configure

АСК) будет принят на обоих концах канала. После этого канал считается от-

крытым и переходит

фазу аутентификации (необязательно);

•

аутентификация

(Authenticate Phase). В этой фазе аутентифицируются

обе точки, используя протоколы РАР (Password Authentication Protocol) или

CHAP (Challenge Handshake Authentication

Protocol).

Канал не переходит

сле-

дующую фазу Network Phase до успешной аутентификации. Если же аутенти-

фикация неуспешна, то канал переходит

фазу прекращения действия канала

Terminate Phase;

• согласование конфигурации протоколов сетевого уровня (Network

Phase).

После того как LCP завершит фазу определения качества канала свя-

зи,

конфигурация сетевых протоколов может быть по отдельности выбрана

соответствующими NCR Сетевые протоколы могут быть

любой момент

выз-

ваны и освобождены для последующего использования. Если LCP закрьгоает

данный

канал,

он информирует об этом протоколы сетевого

уровня,

чтобы они

приняли соответствующие меры;

• прекращение действия канала (Terminate Phase). Эта фаза закрывает

РРР-канал административньп^ путем. Иногда это происходит и из-за какого-

нибудь физического события, такого, как плохое качество линии, потеря носи-

теля или истечение периода бездействия таймера. Протокол LCP использует

Terminate Request пакет для закрытия канала и сообщает соответствующим

NCP, что канал закрыт.

Протокол управления

канала связи LCP (Link Control Protocol). LCP обес-

печивает метод оргаьшзации, выбора конфигурации, поддержания

окончаршя

работы канала с непосредственным соедршением.

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

для организации

канала

связи.

Используются

для

организации

и выбора

кон-

фигурации

канала.

для завершения действия канала. Применяются для завершения действия

канала связи.

для поддержания работоспособности канала. Используются для поддержа-

ния

и отладки

канала.

К таким

пакетам относятся, например, пакеты LQR (Link

Quality Report) и Echo Request/Reply, обеспечивающие мониторинг качества

стандартного синхронного

канала LQM

(Lmk Quality Monitoring).

LCP пакет передается в поле Information РРР-кадра. Формат пакета связи

протокола LCP представлен на рис. 5.13.

346

5.4.

Протоколы

IVуровня стека TCP/IP

Flag

(ТЕ)

Address

(FF)

Control

(03)

Mformation

FCS

Flag

(ТЕ)

LCP пакет Cxxx Code

Identifier

Length Data

Code=l или Code=2 \

Type

Length Value

Параметр 1

^-— >

Type

Length

Value

Параметр 2

Рис.

5.13.

Формат пакета LCP

Поле Code определяет тип LCP-сообщения, содержащегося

поле данных.

Ниже приведены некоторые общие примеры LCP пакетов для организации ка-

нала.

L Configure Request (Code = 1):

а) открытие соединения;

б)

обмен параметрами конфигурации;

в) прием оговоренных параметров от другой стороны.

Configure Аск (Code = 2):

а) ответ на Configure Request;

б) указание на то, что значения параметров, полученных в Configure

Request, корректны;

в) сигнализирует, что канал открьгг по прибьггию пакета.

Configure Nak (Code = 3) показывает, что значения параметров неприем-

лемы.

Configure Reject (Code = 4):

а) указывает, что некоторые из параметров неприемлемы;

б) шлет новый Configure Request пакет без неправильных параметров,

найденных в отвергнутом пакете.

Поле Identifier определяет запросы и ответы. Поле Length указывает раз-

мер LCP-пакета. Поле Data содержит конфигурационные параметры для паке-

тов

типа Configure Request

Configure Аск, определяемые полями

Туре,

Length

Value.

Всего

может

быгь задано

восемь параметров

конфигурации.

Поле

Туре

описывает параметры конфигурации

для

согласования,

поле

Length описьшает

их длину,

поле Value определяет значение параметров конфигурации для со-

гласования. В табл. 5.7 представлены параметры конфигурации LCP.

347

5. Сетевые

протоколы

Параметр

Maximum

Receive Unit

Async-Control

Character-Map

Authentication-

Protocol

Quality-

Protocol

Magic-Number

RESERVED

Protocol-Field-

Compressed

Address-and-

Control Field-

Compressed

FCS-

Altematives

Таблица

5.7.

Параметры конфигурации LCP

Описание

Согласует размеры пакетов

одного направления

Согласует использование

управляющих символов для

асинхронных линий

Используется для аутенти-

фикации, до того как начнет-

ся обмен пакетами третьего

уровня

Определяет мониторинг

качества канала

Определяет закольцован-

ность канала и другие

аномалии на втором уровне

—

Согласует протокол сжатия

на втором уровне

Согласует сжатие полей

Address и Control РРР-кадра

Согласует 32-бит FCS

Тип

Длина,

байт

—

Значение

1500

(по умолчанию)

FFFFFFFF

(по умолчанию)

С023 (РАР)

С223(СНАР)

Нет

(по умолчанию)

С025 (LQR)

Нет

(по умолчанию)

—

Запрещено

(по умолчанию)

Не сжимать

(по умолчанию)

16бигРС8

(по умолчанию)

Семейство протоколов управления сетью NCP{Network Control

Protocols). После фазы LCP в РРР-канале следует фаза согласования пара-

метров, специфичных для каждого из протоколов сетевого уровня в NCP.

Например, протокол

требует от обоих концов обмена и приема соответству-

ющих IP-адресов. NCP определяет, каким образом данные различных прото-

колов расположены внутри РРР-кадра, что описано отдельным соглашением

RFC,

определяющим как данный протокол инкапсулируется в РРР-кадр. Каж-

дый NCP устанавливает, обслуживает и закрьгоает использование определен-

ного протокола. На рис. 5.14 показан пример NCP кодов, которые могут нахо-

диться в поле Protocol РРР-кадра.

Аутентификация для РРР описана

в RFC

1334.

Она

использует

два

протокола

РАР

и CHAR Последний наиболее распространен

современных сетях. СНАР-

аутентификация является частью фазы установления соединения LCP и повто-

ряется через определенные интервалы времени, когда РРР-канал установлен.

348

5.4.

Протоколы IVуровня стека TCP/IP

Flag

(ТЕ)

Address

(FF)

Control

(03)

Information

FCS

Flag

(7E)

Protocol

^4^

Data

8021

8023

8025

8027

IP 1

OSI

XNS,

VINES

DECnet 1

Рис. 5.14. Пример ЛСР-кодов

Flag

(7E)

Address

(FF)

Control

(03)

^formation

FCS

Flag

(7E)

LCP-пакет

C223 Code Identifier Length Value Size Hash Value CHAP Local Name

I l=Challenge

" 2=Response

' 3=Success

• 4=Failure

Указывает на CHAP

Обмен СНАР-пакетами

Challenge

^ Response

Success

Рис.

5.15. СНЬ^Р-аутентификация

CHAP выполняется на каждой стороне канала и каждой стороне назначается

одинаковый открытый ключ - secret, на базе которого вычисляется уникальное

значерше Hash Value, помещаемое в пакет (рис. 5.15). Аутентификация реали-

зуется по алгоритму с открыгым ключом.

Мониторинг качества канала LQM {Link Quality Monitoring). Монито-

ринг поддерживается только на стандартных синхронных каналах. Качество

канала определяется процентом успепшо переданных

или

полученных пакетов

в пределах отчетного периода. Эти пакеты называются LQR (Link Quality

Report). Процедура LQM использует LQR-пакеты, содержащие счетчики для

определения входного и выходного качества канала для входных и выходных

пакетов. Отчетный период описывается

конфигурации. После пяти отчетных

периодов LQM вычисляет среднее значение процента переданных и принятых

пакетов и сравнивает его с пороговым значением. Если средний процент мень-

ше,

чем пороговое значение, то соответствующий NCP закрывается. В допол-

349