Информатика в техническом университете / Информатика в техническом университете. Телекоммуникации и сети

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-пакет добавляется один байт-разделитель (между пакета­ ми они не дублируются), а иногда появляется несколько дополнительных бай­ тов, вставляемых по процедуре вставки байта.

Рис. 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 такие процедуры не предусмотре­ ны. Эти функции обеспечивают вышележащие протоколы: протокол DP прово­ дит тестирование целостности пакета по заголовку 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

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

закроют этот канал или пока не произойдет какое-нибудь внешнее событие (на­ пример, истечет срок бездействия таймера или вмешается какой-нибуць пользо­ ватель).

Требования к интерфейсам физического уровня, РРР может работать

через любой интерфейс 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 (Приложение 1: Стартстопная передача). ISO 3309-1979 определяет структуру блока данных HLDC для применершя в синх­ ронных режимах передачи. ISO 3309-1984/PDADl определяет предложенные для стандарта ISO 3309-1979 модификации, которые позволяют его использо­ вание в асинхронных режимах. Формат блока данных РРР приведен на рис. 5.12.

Длина поля Flag составляет 1 байт; она указьгоает на начало или конец бло­ ка данных. Эта последовательность состоит из бинарной последовательности 01111110-(7Е)л.

Длина поля y4ddress тоже равна 1 байт; оно содержит бинарную последова­ тельность 11111111- (РР)л, представляющую собой стандартный широковеща­ тельный адрес. РРР не присваивает индивидуальньпс адресов станциям.

Поле Control составляет 1 байт; содержит информацию о предоставляемых услугах.

Длина поля Protocol равна 2 байт; его значение идентифицирует протокол, заключенный в информационном поле блока данных. Значения поля Protocol и соответствующие им пакеты представлены в табл. 5.6.

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

344

Поле 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.13. Формат пакета LCP

Поле Code определяет тип LCP-сообщения, содержащегося в поле данных. Ниже приведены некоторые общие примеры LCP пакетов для организации ка­ нала.

L Configure Request (Code = 1): а) открытие соединения;

б) обмен параметрами конфигурации; в) прием оговоренных параметров от другой стороны.

2. Configure Аск (Code = 2):

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

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

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

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

4.Configure Reject (Code = 4):

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

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

Поле Identifier определяет запросы и ответы. Поле Length указывает раз­ мер LCP-пакета. Поле Data содержит конфигурационные параметры для паке­ тов типа Configure Request и Configure Аск, определяемые полями Туре, Length и Value. Всего может быгь задано восемь параметров конфигурации. Поле Туре описывает параметры конфигурации для согласования, поле Length описьшает их длину, а поле Value определяет значение параметров конфигурации для со­ гласования. В табл. 5.7 представлены параметры конфигурации LCP.

347

Семейство протоколов управления сетью NCP{Network Control Protocols). После фазы LCP в РРР-канале следует фаза согласования пара­ метров, специфичных для каждого из протоколов сетевого уровня в NCP. Например, протокол IP требует от обоих концов обмена и приема соответству­ ющих IP-адресов. NCP определяет, каким образом данные различных прото­ колов расположены внутри РРР-кадра, что описано отдельным соглашением RFC, определяющим как данный протокол инкапсулируется в РРР-кадр. Каж­ дый NCP устанавливает, обслуживает и закрьгоает использование определен­ ного протокола. На рис. 5.14 показан пример NCP кодов, которые могут нахо­ диться в поле Protocol РРР-кадра.

Аутентификация для РРР описана в RFC 1334. Она использует два протокола РАР и CHAR Последний наиболее распространен в современных сетях. СНАРаутентификация является частью фазы установления соединения LCP и повто­ ряется через определенные интервалы времени, когда РРР-канал установлен.

348

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

CHAP выполняется на каждой стороне канала и каждой стороне назначается одинаковый открытый ключ - secret, на базе которого вычисляется уникальное значерше Hash Value, помещаемое в пакет (рис. 5.15). Аутентификация реали­ зуется по алгоритму с открыгым ключом.

Мониторинг качества канала LQM {Link Quality Monitoring). Монито­ ринг поддерживается только на стандартных синхронных каналах. Качество канала определяется процентом успепшо переданных или полученных пакетов в пределах отчетного периода. Эти пакеты называются LQR (Link Quality Report). Процедура LQM использует LQR-пакеты, содержащие счетчики для определения входного и выходного качества канала для входных и выходных пакетов. Отчетный период описывается в конфигурации. После пяти отчетных периодов LQM вычисляет среднее значение процента переданных и принятых пакетов и сравнивает его с пороговым значением. Если средний процент мень­ ше, чем пороговое значение, то соответствующий NCP закрывается. В допол-

349