Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
4.5 Протоколы связей "точка-точка"
Датаграммы IP могут передаваться по связям "точка-точка" между парой хостов, хостом и маршрутизатором или парой маршрутизаторов. Протокол IP передает датаграмму посредством множества различных взаимодействий TCP или UDP по одиночной связи "точка-точка".
IP не знает и не заботится об идентичности приложения-источника и приложения-приемника. Каждый раз, когда IP сталкивается с исходящей датаграммой, он передает ее так, как это специфицировано в данном протоколе. Как иллюстрирует рис. 4.4, совместно использовать одну связь могут трафики различных взаимодействий клиент/сервер — примерно так же, как различные автомобили используют одну автостраду.
Рис. 4.4. Множество клиентов и серверов совместно используют одну сетевую связь.
В настоящее время трафик IP, пересылаемый по связям "точка-точка", пакетируется несколькими различными способами:
■ с использованием общепринятой версии протокола "точка-точка" HDLC
■ через стандартный протокол Интернета РРР
■ с использованием протокола SLIP
Понемногу реализации перемещаются в сторону стандарта Интернета PPP, который имеет множество разнообразных возможностей.
4.6 HDLC
Протокол управления высокоуровневой связью данных (High-level Data Link Control — HDLC) является международным стандартом для связи "точка-точка" начиная с 60-х годов. HDLC пересылает серию данных как синхронизированный по времени поток бит, разделенный на кадры. Каждый кадр отделяется специальным шаблоном (флажком):
0 1 1 1 1 1 1 0
Для распознавания этого шаблона необходимо исключить его возникновение в пользовательских данных. Для этого после пересылки флажка открытия кадра передающая аппаратура вставляет нули после каждых пяти последовательных единиц в пользовательских данных. Такой способ называется вставкой нулевого бита (zero-bit insertion) или набивкой битов (bit-stuffing).
После выявления начала кадра приемник на другом конце связи выполняет удаление всех нулей после каждых пяти последовательных единиц внутри кадра (это делается на аппаратном уровне).
На рис. 4.5 показаны данные до и после вставки дополнительных битов.
Рис. 4.5. Вставка нулевого бита в HDLC
4.6.1 Формат кадра HDLC
Использование шаблона в протоколе HDLC влияет на всю структуру формата кадра. На рис. 4.6 показан информационный кадр HDLC, имеющий заголовок, данные и завершающую секцию, которая содержит контрольную последовательность кадра (Frame Check Sequence — FCS). Октет шаблона применяется как разделитель в начале и в конце кадра.
Рис. 4.6. Формат кадра HDLC с разделителями
FCS создается в результате математического вычисления на основе содержимого кадра. Полученный результат называется циклической избыточной суммой (Cyclic Redundancy Check — CRC), и некоторые авторы используют для именования завершающей секции кадра название CRC, а не FCS. Аналогичные вычисления выполняются в точке назначения связи. Если полученный при этом результат не будет равен значению поля FCS, значит, некоторые биты кадра изменились при пересылке и кадр должен игнорироваться как содержащий ошибку.
Использование контрольной последовательности кадра — это очень полезная идея. Поле FCS можно обнаружить практически во всех кадрах локальных и региональных сетей.
Заголовок кадра HDLC имеет поле адреса назначения (destination address). Такое поле необходимо для многоточечной (multipoint) версии протокола HDLC (например, в протоколе Synchronous Data Link Control (SDLC) компании IBM), которая позволяет нескольким системам совместно использовать одну линию. Каждой системе присваивается собственный адрес, а трафик этой системы перенаправляется в соответствии с адресом в заголовке кадра.
IP не использует технологию многоточечной линии связи, и передаваемые в кадрах HDLC датаграммы IP имеют своим адресом двоичное значение 11111111 (шестнадцатеричное X'FF), которое называется широковещательным адресом (broadcast), определяющим пересылку кадра на все станции сети. (Далее в книге для записи шестнадцатеричных чисел используется формат X'N, где X указывает на шестнадцатеричное число, N — представляет само число, а "'" — разделяет два поля такой записи.— Прим. пер.)
Заголовок кадра HDLC имеет поле управления (control). Некоторые протоколы связи помещают в это поле номера пересылаемых кадров или номера кадров для подтверждения их получения. Примерами могут служить протоколы SDLC и LAPB, использующие поле управления для нумерации, подтверждения приема и повторной трансляции кадров. Такие протоколы выполняют повторную пересылку тех кадров, для которых не получено подтверждение их получения приемником за заданный интервал времени.
Кадры, переносящие датаграммы IP, как и кадры для пересылки данных других протоколов, например IPX или DECnet, не требуют нумерации и подтверждения. Для IP и других похожих протоколов в управляющем поле записывается значение X'03, указывающее на нечисловой информационный кадр (Unnumbered Information frame) протокола HDLC.
Таким образом, датаграммы IP в кадрах HDLC имеют формат, представленный на рис. 4.7.
Рис. 4.7. Формат кадра HDLC, передающего датаграмму IP
Обобщив, можно отметить, что при пересылке датаграмм IP в кадрах HDLC:
■ Используется широковещательный адрес X'FF.
■ Управляющее поле имеет значение X'03 — нечисловой информационный кадр.
4.6.2 Недостатки HDLC
То, что HDLC является стандартом, еще не означает успешного взаимодействия друг с другом связей "точка-точка" между различными реализациями интерфейсов HDLC.
В HDLC определено множество дополнительных и необязательных возможностей, что приводит к различным "стандартным" реализациям HDLC. Еще более запутывает ситуацию предоставление многими разработчиками собственных версий HDLC для интерфейсов "точка-точка".
В результате долгое время не было единого стандарта для коммуникаций "точка-точка", что существенно затрудняло использование оборудования от различных производителей.
Разработка HDLC была выполнена до появления многопротокольных сетей. Однако сегодня многие линии "точка-точка" служат для пересылки трафика от различных протоколов, что приводит к дополнительным проблемам.
Решение этих вопросов поручено комитету IETF.
4.7 Протокол PPP
Рабочая группа IETF предложила решение на основе протокола "точка-точка" (Point-to-Point Protocol — PPP). PPP может использоваться в любой полнодуплексной цепи — синхронной с пересылкой битов или асинхронной (старт/стоп) с пересылкой байтов. Этот протокол пригоден для медленных последовательных линий связи, быстрых выделенных линий, ISDN или волоконно-оптических каналов SONET. PPP был разработан для пересылки PDU различных протоколов — IP, IPX, DECnet, ISO и т.д. Кроме того, PPP обеспечивает пересылку данных через сетевые мосты.
PPP содержит несколько подпротоколов. Например:
■ Протокол управления связью (Link Control Protocol) служит для установки, проверки, конфигурирования и закрытия сетевой связи.
■ Протокол управления сетью (Network Control Protocol) предназначен для инициализации, конфигурирования и завершения использования отдельного сетевого протокола. Индивидуальный протокол Network Control Protocol определен для IP, IPX, DECnet, ISO и т.д.
Типичный сценарий РРР выполняется следующим образом:
■ Начинающая соединение по PPP система посылает кадр Link Control. Ее партнер отвечает дополнительным кадром Link Control, устанавливая параметры связи.
■ Проводится обмен кадрами Network Control Protocol для выбора и конфигурирования используемых протоколов сетевого уровня.
■ Данные выбранного протокола пересылаются по связи в кадрах PPP. Каждый кадр имеет поле заголовка, идентифицирующее тип протокола для содержащихся в кадре данных.
■ Для завершения связи применяется обмен кадрами Link Control и Network Control.
Заголовок кадра PPP похож на заголовок HDLC, но содержит одно дополнительное поле для идентификации протокола следующего уровня. На рис. 4.8 показан формат кадра PPP с датаграммой IP. Адресное поле имеет значение X'FF (широковещательная рассылка), а управляющее поле — X'03 (нечисловая информация). Дополнительное поле протокола (protocol field) имеет значение X'00-21, что соответствует пересылке датаграмм IP. Номера для протоколов определены в документе RFC Assigned Numbers (присвоенные номера) от IANA.
Рис. 4.8. Формат кадра PPP, переносящего датаграмму IP
4.7.1 Сжатие в PPP
Может показаться не очень разумным включение одних и тех же октетов адреса и управления в каждый кадр. Партнеры на каждом конце связи PPP могут работать в режиме сжатия (compression) для исключения этих полей.
