Глава 4 Технологии физического уровня и уровня связи данных
4.1 Введение
За последние несколько лет было предложено беспрецедентное количество новых технологий для локальных и региональных сетей, быстро утвердившихся на компьютерном рынке. Произошел огромный скачок от технологий носителей на витых парах и волоконной оптики — скачок, который никто не мог предвидеть. Сети ISDN, Frame Relay, T1, Fractional T1, T3, волоконно-оптические линии SONET, SMDS, новые кабельные соединители и технология ATM обеспечивают связь с обширными территориями, которая становится все быстрее и дешевле.
Организация IETF быстро реагирует на каждую новую технологию, создавая спецификацию для работы с IP в новом носителе и для других протоколов. Следом за ними разработчики маршрутизаторов создают аппаратные интерфейсы и драйверы, дающие пользователям возможность ощутить все преимущества новых технологий.
Работа IETF видна по большой серии RFC, в том числе:
The Point-to-Point Protocol (РРР) for the Transmission of Multiprotocol Datagrams over Point-to-Point Links (Протокол РРР для пересылки многопротокольных датаграмм по соединениям "точка-точка")
Standard for the transmission of IP datagrams over IEEE 802 networks (Стандарт для пересылки датаграмм IP по сетям IEEE 802)
Transmission of IP and ARP over FDDI Networks (Пересылка IP и ARP по сетям FDDI)
Classical IP and ARP over ATM (Классические пересылки IP и ARP по сетям ATM)
4.2 Функции физического уровня, управление доступом к физическому носителю и уровень связи данных
В этой главе мы рассмотрим работу IP поверх различных технологий нижнего уровня. Однако сначала обратимся к происходящим на этих уровнях событиям (см. рис. 4.1).
Рис. 4.1. Функции нижних уровней
Физический уровень определяет кабели, соединители и электрические характеристики носителя. Правила представления логических единиц и нулей в носителе описываются на физическом уровне.
Пересылаемые данные для сохранения их смысла пакетируются в кадры (некоторые авторы называют такие элементы пакетами). Кадр переносит информацию по отдельной связи. Для достижения места (точки) назначения датаграмма IP может перемещаться по нескольких связям.
Описание формата кадра принадлежит уровню связи данных. Формат кадра различается в разных технологиях нижнего уровня, используемых для создания связи (например, линии Т1, цепи Frame Relay или локальные сети Ethernet). Каждый кадр имеет заголовок, содержащий сведения, необходимые для его доставки по связи. Формат заголовка зависит от применяемой технологии.
4.3 Сетевые технологии
Все сетевые технологии можно разделить на четыре категории:
1. Связи "точка-точка" в региональных сетях
2. Локальные сети
3. Службы доставки пакетов региональных сетей
4. Службы коммутации ячеек
Для каждой технологии необходим механизм, который:
■ идентифицирует место назначения, когда один интерфейс обслуживает несколько систем (например, интерфейс локальных сетей)
■ выявляет ошибки при пересылке данных
На сегодняшний день многопротокольным окружением стали как локальные, так и региональные сети. Как показано на рис. 4.2, связи часто совместно используются несколькими протоколами (например, TCP/IP, Novell IPX/SPX, DECnet или Vines); эти же связи применяются при перенаправлении трафика. Многопротокольные хосты и маршрутизаторы должны иметь возможность сортировки различных типов трафика и, следовательно, иметь механизмы для:
■ идентификации типа протокола для PDU, используемого в каждом кадре.
Рис. 4.2. Несколько протоколов совместно используют один носитель.
Определение типа протокола представляется не очень сложной работой. Нужно иметь стандартный список протоколов, присвоить каждому из них уникальный номер и поместить такой номер в одно из полей заголовка кадра.
Однако проблема в том, что для описания типа протокола существует несколько стандартов, каждый из которых определяет собственный подход к идентификации полей и присвоенных протоколам номеров. В этой главе мы познакомимся с различными форматами, используемыми в наиболее распространенных технологиях пересылки данных.
4.4. Извлечение данных из пакетов
В соревнованиях по многоборью спортсмены сначала преодолевают один из участков вплавь, далее пересаживаются на велосипед и т.д. Протокол IP работает подобным же образом: датаграмма перемещается из одной среды передачи в другую (из одного носителя в другой), пока не достигнет пункта назначения.
Перед тем как датаграмма будет передана по сетевой связи, она заключается в соответствующий этой связи кадр. После получения кадра маршрутизатор (см. рис. 4.3):
■ удаляет обрамление кадра и извлекает датаграмму
■ анализирует IP-адрес назначения датаграммы и выбирает следующий носитель для дальнейшей пересылки
■ заключает датаграмму в новый кадр (пакетирует ее) и передает по следующей связи, направляя ее далее по маршруту
Рис. 4.3. Извлечение данных из пакета
Перейдем к более детальному описанию и обсудим способы пакетирования данных для различного типа сетевых технологий. Начнем со связей "точка-точка".
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.
Протокол управления высокоуровневой связью данных (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) для исключения этих полей.
Значения в поле протокола указывают, является ли содержимое кадра сообщением Link Control или Network Control, либо полезной информацией (например, датаграммой IP). При установке связи по PPP поле протокола имеет длину 16 бит, но далее при пересылке полезной информации его длина может быть сокращена до 8 бит. Следовательно, датаграмма может быть пакетирована более эффективно (см. рис. 4.9).
Рис. 4.9. Кадр PPP в сжатом формате
Еще одной возможностью в PPP является сжатие методом Вана Джекобсона, позволяющее исключить лишние байты, пересылаемые в сеансе TCP. Заголовки IP и TCP вместе имеют длину от 40 байт и более. Сжатие методом Вана Джекобсона уменьшает типичную 40-байтовую комбинацию до 3, 4 или 5 байт. Для этого оба партнера должны сохранять первоначальные заголовки. При изменениях во время сеанса TCP будут пересылаться только измененные значения в заголовках. Поскольку большая часть используемой в заголовках информации имеет статическую природу, объем пересылаемых изменений будет незначителен.
Рабочая группа 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) для исключения этих полей.
Значения в поле протокола указывают, является ли содержимое кадра сообщением Link Control или Network Control, либо полезной информацией (например, датаграммой IP). При установке связи по PPP поле протокола имеет длину 16 бит, но далее при пересылке полезной информации его длина может быть сокращена до 8 бит. Следовательно, датаграмма может быть пакетирована более эффективно (см. рис. 4.9).
Рис. 4.9. Кадр PPP в сжатом формате
Еще одной возможностью в PPP является сжатие методом Вана Джекобсона, позволяющее исключить лишние байты, пересылаемые в сеансе TCP. Заголовки IP и TCP вместе имеют длину от 40 байт и более. Сжатие методом Вана Джекобсона уменьшает типичную 40-байтовую комбинацию до 3, 4 или 5 байт. Для этого оба партнера должны сохранять первоначальные заголовки. При изменениях во время сеанса TCP будут пересылаться только измененные значения в заголовках. Поскольку большая часть используемой в заголовках информации имеет статическую природу, объем пересылаемых изменений будет незначителен.
4.8 Дополнительный возможности PPP
Рабочая группа по PPP решила и несколько дополнительных проблем, которые могут возникнуть при использовании связей "точка/точка".
4.8.1 Аутентификация
Протокол PPP часто используется для удаленных коммуникаций и связи мобильного пользователя по коммутируемым соединениям. Коммутируемые соединения (dialup connection) иногда применяются для связи локальных сетей подразделений компании с сетью главного офиса.
Перед тем как разрешить внешней системе соединиться с сетью по коммутируемому соединению, следует провести аутентификацию такой системы. В настоящее время PPP поддерживает два способа аутентификации:
■ Простой протокол аутентификации по паролю (Password Authentication Protocol — PAP). В этом случае используются идентификатор пользователя и его пароль, которые вкладываются в кадры, пересылаемые по связи в процессе ее создания.
■ Протокол аутентификации по взаимной проверке (Challenge Handshake Authentication Protocol — CHAP).
Метод взаимной проверки был рассмотрен в главе 3 и не представляет особых трудностей при изучении. Как показано на рис. 4.10:
1. По связи открытым текстом пересылается имя пользователя.
2. Удаленный партнер отвечает случайным проверочным сообщением.
3. Локальная система вычисляет резюме сообщения (используя содержание сообщения и пароль пользователя как входную информацию) и отсылает обратно ответ.
4. Удаленный партнер на основе пароля выполняет те же самые вычисления и сравнивает полученные результаты.
Рис. 4.10. Взаимная проверка в PPP
Подглядывающий за работой сети злоумышленник будет видеть при каждом установлении соединения различные бессмысленные байты. При использовании 16-байтового пароля практически невозможно определить его, подглядывая за сетевым соединением.
4.8.2 Автоматическое отслеживание качества связи
Часто PPP используется между двумя маршрутизаторами. Иногда со временем ухудшается качество соединения. Было бы неплохо заранее определять опасное состояние связи, для чего предусматривается автоматическое выполнение некоторых операций. Например, маршрутизатор может завершить коммутируемое соединение и провести повторный набор телефонного номера для воссоздания этого соединения. Если аналогичная проблема возникает в выделенной линии, то, возможно, придется временно переключить трафик на резервный канал связи.
В PPP реализован очень простой и эффективный способ проверки качества связи. При мониторинге состояния связи подсчитывается количество посланных и полученных кадров и октетов с учетом игнорируемых и ошибочных. Периодически полученный отчет передается на другой конец связи.
Такие сведения позволяют провести анализ произошедших в связи событий. Например, если за определенный интервал времени было послано 100 000 октетов, а партнер успешно получил только 50 000, то ясно, что со связью не все в порядке.
Рабочая группа по PPP решила и несколько дополнительных проблем, которые могут возникнуть при использовании связей "точка/точка".
4.8.1 Аутентификация
Протокол PPP часто используется для удаленных коммуникаций и связи мобильного пользователя по коммутируемым соединениям. Коммутируемые соединения (dialup connection) иногда применяются для связи локальных сетей подразделений компании с сетью главного офиса.
Перед тем как разрешить внешней системе соединиться с сетью по коммутируемому соединению, следует провести аутентификацию такой системы. В настоящее время PPP поддерживает два способа аутентификации:
■ Простой протокол аутентификации по паролю (Password Authentication Protocol — PAP). В этом случае используются идентификатор пользователя и его пароль, которые вкладываются в кадры, пересылаемые по связи в процессе ее создания.
■ Протокол аутентификации по взаимной проверке (Challenge Handshake Authentication Protocol — CHAP).
Метод взаимной проверки был рассмотрен в главе 3 и не представляет особых трудностей при изучении. Как показано на рис. 4.10:
1. По связи открытым текстом пересылается имя пользователя.
2. Удаленный партнер отвечает случайным проверочным сообщением.
3. Локальная система вычисляет резюме сообщения (используя содержание сообщения и пароль пользователя как входную информацию) и отсылает обратно ответ.
4. Удаленный партнер на основе пароля выполняет те же самые вычисления и сравнивает полученные результаты.
Рис. 4.10. Взаимная проверка в PPP
Подглядывающий за работой сети злоумышленник будет видеть при каждом установлении соединения различные бессмысленные байты. При использовании 16-байтового пароля практически невозможно определить его, подглядывая за сетевым соединением.
4.8.2 Автоматическое отслеживание качества связи
Часто PPP используется между двумя маршрутизаторами. Иногда со временем ухудшается качество соединения. Было бы неплохо заранее определять опасное состояние связи, для чего предусматривается автоматическое выполнение некоторых операций. Например, маршрутизатор может завершить коммутируемое соединение и провести повторный набор телефонного номера для воссоздания этого соединения. Если аналогичная проблема возникает в выделенной линии, то, возможно, придется временно переключить трафик на резервный канал связи.
В PPP реализован очень простой и эффективный способ проверки качества связи. При мониторинге состояния связи подсчитывается количество посланных и полученных кадров и октетов с учетом игнорируемых и ошибочных. Периодически полученный отчет передается на другой конец связи.
Такие сведения позволяют провести анализ произошедших в связи событий. Например, если за определенный интервал времени было послано 100 000 октетов, а партнер успешно получил только 50 000, то ясно, что со связью не все в порядке.
4.9 Протокол SLIP
Протокол интерфейса последовательной линии связи (Serial Line Interface Protocol — SLIP), созданный до PPP, обеспечивает уже устаревшие методы пересылки датаграмм IP по последовательной линии связи.
SLIP — наиболее примитивный из всех разработанных протоколов. Датаграмма IP просто пересылается по последовательной линии, байт за байтом. SLIP маркирует конец датаграммы специальным разделительным байтом: 11000000 (X'C0). Что же произойдет, когда такой байт появится в самой датаграмме? Передающая часть SLIP использует Esc-последовательность, которую принимающая часть SLIP преобразует обратно в реальные данные:
С0 в данных → DB DC
DB в данных → DB DD
Обычно SLIP используется для соединения компьютеров PC, Macintosh и Unix с сетями IP по коммутируемым соединениям. Отметим, что SLIP не обеспечивает проверки FCS, передавая выявление ошибок на более высокие уровни. SLIP не обеспечивает пересылки никаких протоколов, кроме IP.
Протокол SLIP со сжатием (Compressed SLIP — CSLIP) является улучшенной версией протокола SLIP, производящей сжатие заголовков TCP/IP методом Вана Джекобсона и обеспечивающей лучшую производительность, чем SLIP.
SLIP можно использовать между хостами, хостом и маршрутизатором или между маршрутизаторами. На рис. 4.11 показан коммуникационный сервер, поддерживающий работу неинтеллектуальных терминалов ASCII и коммутируемые соединения с терминалами по SLIP. Для трафика SLIP данное устройство работает как маршрутизатор IP.
Рис. 4.11. Подключение терминала ASCII и соединения SLIP
Наиболее привлекательным свойством SLIP является его широкое распространение. Наиболее неприятное свойство этого протокола состоит в том, что пользователь рабочей станции должен написать сценарий, который будет читать приглашение от коммуникационного сервера и посылать на сервер идентификатор пользователя, пароль и другую информацию в определенном месте выполнения диалога. PPP имеет большую функциональность и не требует использования сценариев, и вследствие этого понемногу вытесняет SLIP.
4.10 Локальные сети
Рассмотрим, как IP и другие протоколы пакетируют кадры для пересылки по локальным сетям. Классическая локальная сеть предполагает следующие свойства:
■ Станции совместно используют физический носитель.
■ Существуют правила управления доступом к носителю (Media Access Control — MAC), определяющие моменты времени, когда станция может пересылать данные.
■ Данные передаются в кадрах.
Начнем с сетей Ethernet, поскольку они предоставляют наиболее простой пример реализации локальных сетей.
4.11 DIX Ethernet
Локальные сети Ethernet первыми смогли передавать датаграммы IP. Компании Digital Equipment Corporation (DEC), Intel Corporation и Xerox Corporation совместно определили исходную спецификацию DIX Ethernet в 1980 г. Пересмотренная версия 2 этой спецификации появилась в 1982 г.
4.11.1 Носители для DIX Ethernet
Традиционным магистральным носителем для данной технологии является узкополосный коаксиальный кабель. Первоначально применялся жесткий полудюймовый кабель с сопротивлением 50 Ом. Позднее стал использоваться тонкий и более гибкий коаксиальный кабель в 1/4 дюйма, названый thinnet (тонкий сетевой) или cheapernet (дешевый сетевой), а еще позднее многие сети перешли на применение витых пар. Скорость передачи сигналов в 10 Мбит/с превалировала достаточно долгое время, однако сейчас доступна скорость пересылки в 100 Мбит/с. Сегодня DIX Ethernet может работать на широкополосных коаксиальных или волоконно-оптических кабелях.
Различия между вариантами Ethernet отражаются в следующей нотации:
[Скорость пересылки данных в Мбит/с][тип носителя][максимальная длина кабельного сегмента в сотнях метров]
Таким образом, 10BASE5 означает узкополосный (baseband) коаксиальный кабель со скоростью передачи данных в 10 Мбит/с и максимальной длиной сегмента в 500 м. Спецификация для тонкого кабеля 10BASE2 означает узкополосный коаксиальный кабель со скоростью передачи данных в 10 Мбит/с и максимальной длиной сегмента в 200 м.
10BROAD36 должна означать широкополосный коаксиальный кабель со скоростью обмена в 10 Мбит/с и максимальной длиной сегмента в 3600 м. Обозначениями для витых пар и волоконной оптики являются 10BASET и 10BASEF соответственно, хотя это и не вполне согласуется с правилами нотации.
4.11.2 Протокол MAC для DIX Ethernet
DIX Ethernet использует простую процедуру MAC с очень длинным названием: множественный доступ с контролем несущей и обнаружением конфликтов (Carrier Sense Multiple Access with Collision Detection — CSMA/CD).
Интерфейс для работы с данными пакетирует информацию в кадры и прослушивает состояние носителя. Когда носитель свободен, интерфейс начинает пересылку данных (см. рис. 4.12).
Рис. 4.12. Управление доступом к носителю в Ethernet
Заголовок кадра содержит физический адрес интерфейса назначения, часто называемый MAC-адресом. Система с указанным в кадре адресом принимает посланное сообщение и обрабатывает его. Если две или больше станций одновременно начинают пересылку данных, возникает конфликт. Пересылка отменяется на случайный для каждой станции промежуток времени и повторяется снова (каждая станция при этом будет начинать пересылку уже в разное время.— Прим. пер.).
4.11.3 MAC-кадры DIX Ethernet
Формат кадров DIX Ethernet с датаграммами IP показан на рис. 4.13.
Адреса источника и назначения имеют длину по 6 октетов (сами адреса администрируются IEEE). Значение типа в X'08-00 означает пересылку датаграмм IP.
Рис. 4.13. Кадр DIX Ethernet с датаграммой IP
В Ethernet существуют значения типов и для других протоколов (см. документ IANA Assigned Numbers). Носитель может использоваться совместно несколькими протоколами, поскольку в каждом кадре Ethernet идентифицируется тип протокола, что позволяет станции назначения переслать полученную информацию нужной процедуре.
Для правильной работы протокола CSMA/CD требуются кадры длиной не менее 64 октетов. Следовательно, для очень коротких датаграмм нужно будет добавить незначащий заполнитель.
Локальные сети Ethernet первыми смогли передавать датаграммы IP. Компании Digital Equipment Corporation (DEC), Intel Corporation и Xerox Corporation совместно определили исходную спецификацию DIX Ethernet в 1980 г. Пересмотренная версия 2 этой спецификации появилась в 1982 г.
4.11.1 Носители для DIX Ethernet
Традиционным магистральным носителем для данной технологии является узкополосный коаксиальный кабель. Первоначально применялся жесткий полудюймовый кабель с сопротивлением 50 Ом. Позднее стал использоваться тонкий и более гибкий коаксиальный кабель в 1/4 дюйма, названый thinnet (тонкий сетевой) или cheapernet (дешевый сетевой), а еще позднее многие сети перешли на применение витых пар. Скорость передачи сигналов в 10 Мбит/с превалировала достаточно долгое время, однако сейчас доступна скорость пересылки в 100 Мбит/с. Сегодня DIX Ethernet может работать на широкополосных коаксиальных или волоконно-оптических кабелях.
Различия между вариантами Ethernet отражаются в следующей нотации:
[Скорость пересылки данных в Мбит/с][тип носителя][максимальная длина кабельного сегмента в сотнях метров]Таким образом, 10BASE5 означает узкополосный (baseband) коаксиальный кабель со скоростью передачи данных в 10 Мбит/с и максимальной длиной сегмента в 500 м. Спецификация для тонкого кабеля 10BASE2 означает узкополосный коаксиальный кабель со скоростью передачи данных в 10 Мбит/с и максимальной длиной сегмента в 200 м.
10BROAD36 должна означать широкополосный коаксиальный кабель со скоростью обмена в 10 Мбит/с и максимальной длиной сегмента в 3600 м. Обозначениями для витых пар и волоконной оптики являются 10BASET и 10BASEF соответственно, хотя это и не вполне согласуется с правилами нотации.
4.11.2 Протокол MAC для DIX Ethernet
DIX Ethernet использует простую процедуру MAC с очень длинным названием: множественный доступ с контролем несущей и обнаружением конфликтов (Carrier Sense Multiple Access with Collision Detection — CSMA/CD).
Интерфейс для работы с данными пакетирует информацию в кадры и прослушивает состояние носителя. Когда носитель свободен, интерфейс начинает пересылку данных (см. рис. 4.12).
Рис. 4.12. Управление доступом к носителю в Ethernet
Заголовок кадра содержит физический адрес интерфейса назначения, часто называемый MAC-адресом. Система с указанным в кадре адресом принимает посланное сообщение и обрабатывает его. Если две или больше станций одновременно начинают пересылку данных, возникает конфликт. Пересылка отменяется на случайный для каждой станции промежуток времени и повторяется снова (каждая станция при этом будет начинать пересылку уже в разное время.— Прим. пер.).
4.11.3 MAC-кадры DIX Ethernet
Формат кадров DIX Ethernet с датаграммами IP показан на рис. 4.13.
Адреса источника и назначения имеют длину по 6 октетов (сами адреса администрируются IEEE). Значение типа в X'08-00 означает пересылку датаграмм IP.
Рис. 4.13. Кадр DIX Ethernet с датаграммой IP
В Ethernet существуют значения типов и для других протоколов (см. документ IANA Assigned Numbers). Носитель может использоваться совместно несколькими протоколами, поскольку в каждом кадре Ethernet идентифицируется тип протокола, что позволяет станции назначения переслать полученную информацию нужной процедуре.
Для правильной работы протокола CSMA/CD требуются кадры длиной не менее 64 октетов. Следовательно, для очень коротких датаграмм нужно будет добавить незначащий заполнитель.
4.12 Сети по спецификации 802
После того как DIX Ethernet и другие технологии локальных сетей доказали на компьютерном рынке свою полезность, IEEE организовала комитет 802 по разработке и публикации стандартов для технологий локальных сетей.
Стандарты из серии 802, объединяющие разработки разных производителей, были признаны ISO и повторно опубликованы как документы этой организации.
Стандарты 802 касаются физических носителей, управления доступа к носителю и форматов кадров для различных типов локальных сетей. Например:
■ 802.3 описывает несколько измененную версию Ethernet.
■ 802.4 специфицирует широковещательную локальную сеть с пересылкой маркера, разработанную для производственных помещений.
■ 802.5 описывает технологию Token-Ring.
■ 802.6 определяет подсети на основе двойной шины для распределенных очередей (Distributed Queue Dual Bus), использующихся в городских сетях (Metropolitan Area Network — MAN).
4.13 Заголовок LLC для 802.2
Отдельный стандарт 802.2 определяет заголовок управления логической связью (Logical Link Control — LLC), используемый во всех технологиях локальных сетей по спецификациям 802. Заголовок LLC выполняет две задачи:
■ Для кадров OSI идентифицирует протоколы источника и назначения
■ Содержит поля управления
Описание IEEE предполагает множество формальных правил, однако каждый из элементов достаточно прост.
Элементы для назначения и источника протоколов ISO каждого кадра описываются кодами точки доступа к службе назначения (Destination Service Access Point — DSAP) и кодами точки доступа к службе источника (Source Service Access Point — SSAP).
Значения DSAP/SSAP присваиваются протоколам ISO, но не протоколу IP или множеству других протоколов, используемых на практике. Для IP и других распространенных протоколов DSAP и SSAP устанавливаются в значение X'AA, что означает наличие следующего далее другого заголовка, который и будет определять тип протокола для размещенных в кадре данных. Дополнительный заголовок называется подзаголовком протокола доступа в подсети (Subnetwork Access Protocol — SNAP).
Подзаголовок SNAP содержит вводную часть (introducer) со следующим далее старым знакомым — кодом типа Ethernet. Вводная часть имеет прекрасное название — уникальный организационный идентификатор (Organizationally Unique Identifier — OUI). Он определяет, кто несет ответственность за присвоение номеров протоколов.
Вводная часть (OUI) для кодов типа Ethernet (см. рис. 4.14) имеет значение X'00-00-00. Отдельный OUI со значением X'00-80-C2 служит для введения номеров различных протоколов мостов.
Рис. 4.14. Кадр 802.3 с заголовком LLC 802.2 и подзаголовком SNAP
4.13.1 Спецификации 802.3 и 802.2
Стандарт 802.3 содержит описание носителя Ethernet, протокола доступа к носителю CSMA/CD и формата MAC-кадров. В соответствии со стандартами комитета 802 заголовок 802.2 должен включаться в МАС-кадр 802.3.
На рис. 4.14 показан результат размещения датаграммы IP в кадре 802.3/802.2.
■ Отметим, что в отличие от DIX Ethernet третье поле заголовка кадра 802.3 содержит сведения о длине информации, которая следует далее (за исключением заполнителя) вместо кода типа Ethernet. Длина определяется в 8 октетов полей LLC и SNAP. Далее мы увидим, что в заголовке IP размещается поле длины датаграммы, хотя для IP это значение является избыточным.
■ DSAP и SSAP имеют значения X'AA, указывая на следующий далее подзаголовок SNAP.
■ Поле управления содержит X'03, что означает нечисловую информацию — так же, как и в HDLC.
■ Вводная часть поля SNAP содержит X'00-00-00, указывая на следующий далее тип Ethernet (который имеет значение X'08-00).
Другие протоколы (например, IPX или DECnet) имеют похожие кадры — нужно только подставить правильные значения для типов Ethernet.
Отметим, что 8 дополнительных октетов добавлены без каких-либо изменений в функциях IP. Именно поэтому многие реализации продолжают использовать старую спецификацию формата DIX Ethernet. Сетевые адаптеры Ethernet Network Interface Card (интерфейсные карты сети Ethernet) и их программные драйверы обычно поддерживают оба стандарта, а при конфигурировании пользователь может выбрать нужный вариант.
Часто термин Ethernet применяют как для старой DIX, так и для реализации IEEE 802.3/802.2. Иногда очень важно разделять эти понятия, поскольку системы, сконфигурированные для работы с DIX, не могут взаимодействовать с системами, сконфигурированными для 802.3/802.2.
Отдельный стандарт 802.2 определяет заголовок управления логической связью (Logical Link Control — LLC), используемый во всех технологиях локальных сетей по спецификациям 802. Заголовок LLC выполняет две задачи:
■ Для кадров OSI идентифицирует протоколы источника и назначения
■ Содержит поля управления
Описание IEEE предполагает множество формальных правил, однако каждый из элементов достаточно прост.
Элементы для назначения и источника протоколов ISO каждого кадра описываются кодами точки доступа к службе назначения (Destination Service Access Point — DSAP) и кодами точки доступа к службе источника (Source Service Access Point — SSAP).
Значения DSAP/SSAP присваиваются протоколам ISO, но не протоколу IP или множеству других протоколов, используемых на практике. Для IP и других распространенных протоколов DSAP и SSAP устанавливаются в значение X'AA, что означает наличие следующего далее другого заголовка, который и будет определять тип протокола для размещенных в кадре данных. Дополнительный заголовок называется подзаголовком протокола доступа в подсети (Subnetwork Access Protocol — SNAP).
Подзаголовок SNAP содержит вводную часть (introducer) со следующим далее старым знакомым — кодом типа Ethernet. Вводная часть имеет прекрасное название — уникальный организационный идентификатор (Organizationally Unique Identifier — OUI). Он определяет, кто несет ответственность за присвоение номеров протоколов.
Вводная часть (OUI) для кодов типа Ethernet (см. рис. 4.14) имеет значение X'00-00-00. Отдельный OUI со значением X'00-80-C2 служит для введения номеров различных протоколов мостов.
Рис. 4.14. Кадр 802.3 с заголовком LLC 802.2 и подзаголовком SNAP
4.13.1 Спецификации 802.3 и 802.2
Стандарт 802.3 содержит описание носителя Ethernet, протокола доступа к носителю CSMA/CD и формата MAC-кадров. В соответствии со стандартами комитета 802 заголовок 802.2 должен включаться в МАС-кадр 802.3.
На рис. 4.14 показан результат размещения датаграммы IP в кадре 802.3/802.2.
■ Отметим, что в отличие от DIX Ethernet третье поле заголовка кадра 802.3 содержит сведения о длине информации, которая следует далее (за исключением заполнителя) вместо кода типа Ethernet. Длина определяется в 8 октетов полей LLC и SNAP. Далее мы увидим, что в заголовке IP размещается поле длины датаграммы, хотя для IP это значение является избыточным.
■ DSAP и SSAP имеют значения X'AA, указывая на следующий далее подзаголовок SNAP.
■ Поле управления содержит X'03, что означает нечисловую информацию — так же, как и в HDLC.
■ Вводная часть поля SNAP содержит X'00-00-00, указывая на следующий далее тип Ethernet (который имеет значение X'08-00).
Другие протоколы (например, IPX или DECnet) имеют похожие кадры — нужно только подставить правильные значения для типов Ethernet.
Отметим, что 8 дополнительных октетов добавлены без каких-либо изменений в функциях IP. Именно поэтому многие реализации продолжают использовать старую спецификацию формата DIX Ethernet. Сетевые адаптеры Ethernet Network Interface Card (интерфейсные карты сети Ethernet) и их программные драйверы обычно поддерживают оба стандарта, а при конфигурировании пользователь может выбрать нужный вариант.
Часто термин Ethernet применяют как для старой DIX, так и для реализации IEEE 802.3/802.2. Иногда очень важно разделять эти понятия, поскольку системы, сконфигурированные для работы с DIX, не могут взаимодействовать с системами, сконфигурированными для 802.3/802.2.
4.14 Уровни в сетях 802
Ознакомимся со взглядом IEEE на сетевой мир. С появлением локальных сетей 802 IEEE разделил сетевой уровень 2 (уровень связи данных) на два подуровня (см. рис. 4.15).
Рис. 4.15. Уровни для локальных сетей 802
Подуровень MAC обеспечивает правила доступа к носителю — слушать и пересылать для 802.3 или ждать маркера для 802.5. Этот же уровень определяет первую часть заголовка кадра, которая содержит физические адреса источника и назначения.
Подуровень Logical Link Control описывает формат заголовка LLC. Он же определяет достаточно сложные правила для коммуникаций в те моменты, когда производится нумерация, подтверждение пересылки, управление потоком и повторная пересылка кадров с использованием уровня связи данных. Связи, обеспечивающие такие возможности, называются связями типа 2 (Type 2). Существует несколько протоколов, включая SDLC, LAPB или LAPD, которые выполняют коммуникации в локальных сетях с помощью связей типа 2.
Разумеется, датаграммы IP требуют только указания на подуровне Logical Link Control сведений о включении в кадр датаграммы IP. Обычно IP работает поверх протокола связи типа 1.
4.15 Другие технологии локальных сетей
По требованию IEEE локальные сети Token-Ring, token bus и FDDI должны включать заголовок LLC 802.2 и подзаголовок SNAP для пересылки протокола IP или иных протоколов с кодом типа Ethernet. Для них не существует укороченного формата.
Те же самые поля LLC и SNAP определяют вложенный протокол, как показано на рис. 4.14, а именно:
X'AA-AA-03-00-00-00 (тип Ethernet)
4.15.1 Конфигурация и носители для Token-Ring
Локальные сети Token-Ring были представлены компанией IBM, а позднее IEEE стандартизировал их как протокол 802.5. Станции в сети Token-Ring образуют физическое кольцо.
4.15.2 MAC для 802.5
Идея управления доступом к носителю (MAC) на основе маркера, или жетона, достаточно проста. Специальный кадр, называемый маркером (token), передается по кольцу от станции к станции. Когда станция получает такой маркер, она должна отправить данные дальше в течение ограниченного интервала времени. По завершении этого интервала удерживающая маркер станция обязана переслать его следующей станции.
Хотя основная идея не требует пояснений, для протокола пересылки маркера по кольцу нужны более сложные механизмы, чем для сети Ethernet. В частности, протокол для уровня MAC спецификации 802.5 включает процедуры связывания и разъединения кольца Token-Ring, идентификации ближайших соседей, выявления неисправной станции или потерянного маркера, предотвращения циклической пересылки данных и решения проблем с сигналами. Для различных функций 802.5 определяются разные заголовки MAC-уровня. Тип пересылающего данные протокола указывается через заголовки LLC и SNAP, размещенные за информационным полем маршрутизации (Routing Information Field) кадра Token-Ring.
4.15.3 802.4 Token Bus
Стандарт 802.4 описывает широкополосную шину локальной сети на основе коаксиального кабеля, в которой используется маркер для управления доступом к носителю. 802.4 является частью набора протоколов автоматизации производства (Manufacturing Automation Protocol), предлагаемых для использования в промышленных условиях. Сигналы в широкополосном коаксиальном кабеле не подвержены влиянию электромагнитных помех, связанных с промышленным производством. Использование протокола с пересылкой маркера позволяет достичь предсказуемого расписания доступа к локальной сети. Однако 802.4 никогда не имел широкого распространения.
4.15.4 FDDI
Волоконно-оптический интерфейс для распределенных данных (Fiber Distributed Data Interface — FDDI) со скоростью пересылки в 100 Мбит/с часто используется в локальных сетях для создания магистральных соединений, объединяющих низкоскоростные сегменты локальных сетей.
■ FDDI в первую очередь предназначен для использования с волоконно-оптическим кабелем, хотя в отдельных частях сети могут применяться витые пары.
■ Как показано на рис. 4.16, основу FDDI составляет одиночное (или двойное) кольцо, называемое транком (trunk). Станции могут соединяться непосредственно с транком или подключаться к нему через концентраторы. Допустимо подключение к транку древовидной структуры из концентраторов и станций.
■ Когда в качестве транка применяется двойное кольцо, локальная сеть может быть сконфигурирована на восстановление работы при отказе одного из колец. Обычно трафик передается только по одному кольцу транка, но при его отказе начинает применяться второе кольцо, что позволяет обойти неисправность и продолжить работу сети.
Рис. 4.16. Топология сетей FDDI
Доступ к носителю в FDDI производится на основе пересылки маркера. Реально модель MAC-протокола очень похожа на 802.5 Token-Ring.
Кадр FDDI имеет MAC-заголовок и завершающую секцию, а когда кадр служит для пересылки IP, то используются уже знакомые нам заголовки 802.2 LLC и SNAP, отражающие перенос в кадре датаграммы IP.
По требованию IEEE локальные сети Token-Ring, token bus и FDDI должны включать заголовок LLC 802.2 и подзаголовок SNAP для пересылки протокола IP или иных протоколов с кодом типа Ethernet. Для них не существует укороченного формата.
Те же самые поля LLC и SNAP определяют вложенный протокол, как показано на рис. 4.14, а именно:
X'AA-AA-03-00-00-00 (тип Ethernet)
4.15.1 Конфигурация и носители для Token-Ring
Локальные сети Token-Ring были представлены компанией IBM, а позднее IEEE стандартизировал их как протокол 802.5. Станции в сети Token-Ring образуют физическое кольцо.
4.15.2 MAC для 802.5
Идея управления доступом к носителю (MAC) на основе маркера, или жетона, достаточно проста. Специальный кадр, называемый маркером (token), передается по кольцу от станции к станции. Когда станция получает такой маркер, она должна отправить данные дальше в течение ограниченного интервала времени. По завершении этого интервала удерживающая маркер станция обязана переслать его следующей станции.
Хотя основная идея не требует пояснений, для протокола пересылки маркера по кольцу нужны более сложные механизмы, чем для сети Ethernet. В частности, протокол для уровня MAC спецификации 802.5 включает процедуры связывания и разъединения кольца Token-Ring, идентификации ближайших соседей, выявления неисправной станции или потерянного маркера, предотвращения циклической пересылки данных и решения проблем с сигналами. Для различных функций 802.5 определяются разные заголовки MAC-уровня. Тип пересылающего данные протокола указывается через заголовки LLC и SNAP, размещенные за информационным полем маршрутизации (Routing Information Field) кадра Token-Ring.
4.15.3 802.4 Token Bus
Стандарт 802.4 описывает широкополосную шину локальной сети на основе коаксиального кабеля, в которой используется маркер для управления доступом к носителю. 802.4 является частью набора протоколов автоматизации производства (Manufacturing Automation Protocol), предлагаемых для использования в промышленных условиях. Сигналы в широкополосном коаксиальном кабеле не подвержены влиянию электромагнитных помех, связанных с промышленным производством. Использование протокола с пересылкой маркера позволяет достичь предсказуемого расписания доступа к локальной сети. Однако 802.4 никогда не имел широкого распространения.
4.15.4 FDDI
Волоконно-оптический интерфейс для распределенных данных (Fiber Distributed Data Interface — FDDI) со скоростью пересылки в 100 Мбит/с часто используется в локальных сетях для создания магистральных соединений, объединяющих низкоскоростные сегменты локальных сетей.
■ FDDI в первую очередь предназначен для использования с волоконно-оптическим кабелем, хотя в отдельных частях сети могут применяться витые пары.
■ Как показано на рис. 4.16, основу FDDI составляет одиночное (или двойное) кольцо, называемое транком (trunk). Станции могут соединяться непосредственно с транком или подключаться к нему через концентраторы. Допустимо подключение к транку древовидной структуры из концентраторов и станций.
■ Когда в качестве транка применяется двойное кольцо, локальная сеть может быть сконфигурирована на восстановление работы при отказе одного из колец. Обычно трафик передается только по одному кольцу транка, но при его отказе начинает применяться второе кольцо, что позволяет обойти неисправность и продолжить работу сети.
Рис. 4.16. Топология сетей FDDI
Доступ к носителю в FDDI производится на основе пересылки маркера. Реально модель MAC-протокола очень похожа на 802.5 Token-Ring.
Кадр FDDI имеет MAC-заголовок и завершающую секцию, а когда кадр служит для пересылки IP, то используются уже знакомые нам заголовки 802.2 LLC и SNAP, отражающие перенос в кадре датаграммы IP.
4.16 Использование концентраторов
Локальные сети Ethernet, Token-Ring и FDDI вначале существенно различались по топологии кабельных сетей, однако со временем большинство организаций перешло на подключение систем через концентраторы (hub). Эти устройства упрощают администрирование локальных сетей и позволяют перейти на единую физическую топологию — звезду или цепочку звезд.
4.17 Коммутация
Все технологии рассмотренных локальных сетей имеют одно общее свойство: пересылаемый по сети кадр прослушивается всеми станциями сети. Хотя формально кадр предназначен только для одного физического адреса, любой владелец сетевой системы может настроить ее на смешанный режим (promiscuous), когда станция будет захватывать все пересылаемые в сетевом сегменте данные.
Требования к повышению производительности и усилению защиты привели к реализации коммутации трафика. Некоторые интеллектуальные концентраторы проводят переключение при каждой пересылке кадра между источником и приемником, делая его недоступным для остальных станций сети.
4.18 Широковещательные и многоадресные рассылки
Технологии локальных сетей со множественным доступом поддерживают широковещательные рассылки (broadcast). Для этого используется один специальный физический адрес назначения, указывающий, что обработать кадр должны все подключенные к локальной сети интерфейсы. Шестнадцатеричное представление широковещательного адреса можно записать как:
XFF-FF-FF-FF-FF-FF
Сетевой интерфейс можно настроить и на прием кадров, посланных при одной или нескольких многоадресных рассылках (multicast). Многоадресность позволяет кадру попасть на указанный набор сетевых систем. Многоадресная рассылка всегда имеет единицу в младшем бите первого байта адреса:
X'01-00-00-00-00-00
Значения остальных бит устанавливаются в соответствии с конкретной службой многоадресной рассылки.
IANA зарезервировала список физических адресов многоадресных рассылок для нескольких служб. Например, многоадресная рассылка может применяться для передачи сообщения всем мостам сети. Отображение многоадресной рассылки уровня 3 в сетях IP в многоадресную рассылку уровня 2 будет рассмотрено в главе 5.
Термин "одноадресная рассылка" (unicast) применяется для указания уникального физического адреса, присвоенного одному из интерфейсов при выполнении широковещательной или многоадресной рассылки. Если заголовок кадра содержит сведения об одноадресной рассылке, то предполагается доставка такого кадра только одному, указанному сетевому интерфейсу.
Теперь рассмотрим технологии для региональных сетей.
4.19 Сети с коммутацией пакетов
Технология коммутации пакетов была введена в экспериментальном порядке еще в ARPANET. Затем она была улучшена и расширена многими дополнительными возможностями коммуникации данных. Сети с пакетами X.25 получили широкое распространение еще с 80-х годов. Однако большинство пользователей предпочли новую технологию коммутации пакетов Frame Relay, обеспечивающую широкий спектр разнообразных возможностей.
4.20 Сети X.25
Обычная телефонная сеть позволяет соединиться с любым другим абонентом в любой точке планеты. Существует специальная международная организация по стандартам, ответственная за правила объединения национальных телефонных сетей в общемировую систему. Долгое время эта организация называлась Международным консультативным комитетом по телефонной и телеграфной связи (International Telegraph and Telephone Consultative Committee — CCITT). Позднее она была переименована в Сектор стандартизации в телекоммуникациях Международного телекоммуникационного союза (Telecommunication Standardization Sector of the International Telecommunications Unit — ITU-T).
В течение 70-х гг. CCITT начал работу над рекомендациями для создания глобальной цифровой сети. Работа была завершена в 1980 г. Наиболее важной является рекомендация Х.25, определяющая правила для подключения компьютеров к цифровой сети. Точнее, X.25 описывает интерфейс между компьютером, именуемым оборудованием цифрового терминала (data terminal equipment — DTE), и сетевым коммуникационным элементом — оборудованием для терминирования цифровых цепей (data circuit-terminating equipment — DTE) как части сети для личного и общедоступного использования, в последнем случае — для провайдера сетевых услуг.
X.25 устанавливает правила для надежных цепей между компьютерами. Эти цепи именуются виртуальными, поскольку в отличие от телефонной сети во время вызова пользователю не предоставляется фиксированный путь пересылки данных. Реальные связи используются совместно многими конкурирующими виртуальными цепями. Однако такое использование является прозрачным (невидимым) для пользователя цепи.
X.25 получил всемирное признание, и многие общедоступные цифровые сети X.25 соединяют компьютеры в глобальные сообщества.
Цифровые сети X.25 предоставляют цепи двух типов. Коммутируемые виртуальные цепи (switched virtual circuit) производят вызов данных так, как это делается в обычных телефонных сетях (в рекомендации X.121 от CCITT определен 14-значный номер для запросов X.25). Вызывающий абонент набирает 14-значный номер нужного ему компьютера, по которому производится вызов. В другом случае пользователь может применить постоянную виртуальную цепь (permanent virtual circuit), которая работает подобно выделенной телефонной линии.
Рекомендации CCITT не ограничивают внутренней структуры региональных цифровых сетей X.25, однако многие из них используют технологию внутренней коммутации пакетов.
4.20.1 Уровни в X.25
Протокол X.25 имеет три уровня. Уровень связи данных называется балансированным протоколом доступа к связи (Link Access Protocol Balanced — LAPB), а сетевой уровень — уровнем пакетов X.25 (X.25 Packet Level). Владеющий оборудованием DTE пользователь устанавливает связь по X.25 с оборудованием DCE провайдера. Эта связь используется для пересылки данных нескольких виртуальных цепей уровня 3. Коммутируемая виртуальная цепь инициализируется посылкой пакета Call Request (запрос на вызов).
4.20.2 Х.25 и IP
X.25 — одна из многих технологий региональных сетей, способных пересылать датаграммы IP. IP использует виртуальные цепи X.25 таким же способом, как телефонные линии, — "точка-точка", т.е. трафик IP передается между хостами и маршрутизаторами через виртуальные цепи X.25.
Протоколы для связи X.25 (уровня 2) и пакетов X.25 (уровня 3) снимают проблемы правильного порядка передачи данных и коррекции ошибок. Цепи X.25 специально предназначены для создания надежного соединения между конечными точками связи.
Может показаться странным, что ненадежные службы IP работают поверх надежных протоколов X.25. И еще более странным, что, как в X.25, так и в IP реализованы протоколы уровня 3. Однако, учитывая стоимость и общепринятые требования, можно не обращать внимания на нечеткость деления на уровни. Элементы протоколов уровня 3 для сетей VINES, DECnet и SNA могут передаваться по цепям X.25 не менее успешно. Кроме того, данные для работы мостов по уровню 2 также иногда передаются по цепям X.25.
На рис. 4.17 показан трафик IP от нескольких источников, который маршрутизируется по одной виртуальной цепи X.25 и пересылается в несколько различных точек назначения.
Рис. 4.17. Использование сети X.25 для маршрутизации датаграмм IP
4.20.3 Многопротокольный режим поверх X.25
Существуют два метода для пересылки многопротокольного трафика по сети X.25 (аналогичные методы и форматы применяются для пакетного режима ISDN):
1. Для каждого протокола устанавливается отдельная виртуальная цепь. Во время вызова партнеру указывается на пересылаемый протокол.
2. Устанавливается одна виртуальная цепь, совместно используемая несколькими протоколами. Во время вызова указывается на многопротокольный режим. Партнеру сообщается о применяемых протоколах, и соответствующие сведения добавляются в каждый из заголовков пакетов.
Выбор одного из методов определяется тем, насколько службы провайдера могут реализовывать дополнительные виртуальные цепи и как долго выполняются эти процессы.
В зависимости от экономической ситуации система может устанавливать коммутируемое соединение X.25 по умолчанию, когда несколько различных трафиков ожидают пересылки на удаленные сайты. Запрос закрывается по прошествии некоторого периода отсутствия активности. Обработка запроса обычно представляет собой очень медленный процесс, что делает многопротокольный режим более предпочтительным.
4.20.4 IP в отдельной виртуальной цепи X.25
Если трафик IP пересылается по отдельной коммутируемой виртуальной цепи, то это отражается в пакете Call Request протокола X.25, который инициализирует цепь. В этом пакете имеется необязательное поле Call User Data (вызываемые пользователем данные), которое для указания на трафик IP должно содержать значение X'CC.
Значение X'CC является идентификатором протокола сетевого уровня (Network Layer Protocol ID — NLPID), как это установлено для трафика IP организацией ISO.
4.20.5 Другие протоколы в отдельной виртуальной цепи X.25
Несколько других протоколов также имеют коды ISO для NLPID, но коммерческим лицензионным протоколам такие коды не присвоены. Однако, как можно предположить, многие коммерческие протоколы производят присваивание двухбайтового кода типа для общепринятого многопротокольного окружения — Ethernet. Например, трафик AppleTalk имеет код типа Ethernet со значением X'80-9B.
Для запуска в виртуальной цепи одного протокола с присвоением кода типа Ethernet код NLPID должен иметь значение X'80 со следующим далее подзаголовком SNAP, что указывается в поле Call User Data пакета Call Request протокола X.25. Например, для установки виртуальной цепи на работу с трафиком AppleTalk следует послать:
X'80-00-00-00-80-9B
4.20.6 Многопротокольный режим в виртуальной цепи
Если в виртуальной цепи организуется многопротокольный режим, поле Call User Data устанавливается в X'00 и в каждый кадр добавляется дополнительный заголовок, позволяющий идентифицировать тип протокола. Идентификация датаграммы IP очень эффективно выполняется посредством значения IP NLPID, равного X'CC,— это и будет дополнительным заголовком.
Для протоколов, идентификация которых выполняется кодом типа Ethernet, заголовок сообщения начинается NLPID со значением X'80, что указывает на следующий далее подзаголовок SNAP. Например, для цепи с многопротокольным режимом каждому PDU протокола AppleTalk будет предшествовать заголовок:
X'80-00-00-00-80-9B
4.20.7 Пакеты или PDU?
Существует незначительная сложность в способе пересылки информации по Х.25. Некоторые сети X.25 передают пакеты очень маленького размера. Однако передать весь высокоуровневый PDU (например, датаграмму IP) можно через непрерывную последовательность пакетов (packet sequence) с объединением данных в единый PDU на другой стороне цепи (для этого служит флажок "more/nomore" — еще/больше нет). В этом случае идентификатор протокола требуется только в заголовке первого пакета X.25 из пересылаемой последовательности.
Обычная телефонная сеть позволяет соединиться с любым другим абонентом в любой точке планеты. Существует специальная международная организация по стандартам, ответственная за правила объединения национальных телефонных сетей в общемировую систему. Долгое время эта организация называлась Международным консультативным комитетом по телефонной и телеграфной связи (International Telegraph and Telephone Consultative Committee — CCITT). Позднее она была переименована в Сектор стандартизации в телекоммуникациях Международного телекоммуникационного союза (Telecommunication Standardization Sector of the International Telecommunications Unit — ITU-T).
В течение 70-х гг. CCITT начал работу над рекомендациями для создания глобальной цифровой сети. Работа была завершена в 1980 г. Наиболее важной является рекомендация Х.25, определяющая правила для подключения компьютеров к цифровой сети. Точнее, X.25 описывает интерфейс между компьютером, именуемым оборудованием цифрового терминала (data terminal equipment — DTE), и сетевым коммуникационным элементом — оборудованием для терминирования цифровых цепей (data circuit-terminating equipment — DTE) как части сети для личного и общедоступного использования, в последнем случае — для провайдера сетевых услуг.
X.25 устанавливает правила для надежных цепей между компьютерами. Эти цепи именуются виртуальными, поскольку в отличие от телефонной сети во время вызова пользователю не предоставляется фиксированный путь пересылки данных. Реальные связи используются совместно многими конкурирующими виртуальными цепями. Однако такое использование является прозрачным (невидимым) для пользователя цепи.
X.25 получил всемирное признание, и многие общедоступные цифровые сети X.25 соединяют компьютеры в глобальные сообщества.
Цифровые сети X.25 предоставляют цепи двух типов. Коммутируемые виртуальные цепи (switched virtual circuit) производят вызов данных так, как это делается в обычных телефонных сетях (в рекомендации X.121 от CCITT определен 14-значный номер для запросов X.25). Вызывающий абонент набирает 14-значный номер нужного ему компьютера, по которому производится вызов. В другом случае пользователь может применить постоянную виртуальную цепь (permanent virtual circuit), которая работает подобно выделенной телефонной линии.
Рекомендации CCITT не ограничивают внутренней структуры региональных цифровых сетей X.25, однако многие из них используют технологию внутренней коммутации пакетов.
4.20.1 Уровни в X.25
Протокол X.25 имеет три уровня. Уровень связи данных называется балансированным протоколом доступа к связи (Link Access Protocol Balanced — LAPB), а сетевой уровень — уровнем пакетов X.25 (X.25 Packet Level). Владеющий оборудованием DTE пользователь устанавливает связь по X.25 с оборудованием DCE провайдера. Эта связь используется для пересылки данных нескольких виртуальных цепей уровня 3. Коммутируемая виртуальная цепь инициализируется посылкой пакета Call Request (запрос на вызов).
4.20.2 Х.25 и IP
X.25 — одна из многих технологий региональных сетей, способных пересылать датаграммы IP. IP использует виртуальные цепи X.25 таким же способом, как телефонные линии, — "точка-точка", т.е. трафик IP передается между хостами и маршрутизаторами через виртуальные цепи X.25.
Протоколы для связи X.25 (уровня 2) и пакетов X.25 (уровня 3) снимают проблемы правильного порядка передачи данных и коррекции ошибок. Цепи X.25 специально предназначены для создания надежного соединения между конечными точками связи.
Может показаться странным, что ненадежные службы IP работают поверх надежных протоколов X.25. И еще более странным, что, как в X.25, так и в IP реализованы протоколы уровня 3. Однако, учитывая стоимость и общепринятые требования, можно не обращать внимания на нечеткость деления на уровни. Элементы протоколов уровня 3 для сетей VINES, DECnet и SNA могут передаваться по цепям X.25 не менее успешно. Кроме того, данные для работы мостов по уровню 2 также иногда передаются по цепям X.25.
На рис. 4.17 показан трафик IP от нескольких источников, который маршрутизируется по одной виртуальной цепи X.25 и пересылается в несколько различных точек назначения.
Рис. 4.17. Использование сети X.25 для маршрутизации датаграмм IP
4.20.3 Многопротокольный режим поверх X.25
Существуют два метода для пересылки многопротокольного трафика по сети X.25 (аналогичные методы и форматы применяются для пакетного режима ISDN):
1. Для каждого протокола устанавливается отдельная виртуальная цепь. Во время вызова партнеру указывается на пересылаемый протокол.
2. Устанавливается одна виртуальная цепь, совместно используемая несколькими протоколами. Во время вызова указывается на многопротокольный режим. Партнеру сообщается о применяемых протоколах, и соответствующие сведения добавляются в каждый из заголовков пакетов.
Выбор одного из методов определяется тем, насколько службы провайдера могут реализовывать дополнительные виртуальные цепи и как долго выполняются эти процессы.
В зависимости от экономической ситуации система может устанавливать коммутируемое соединение X.25 по умолчанию, когда несколько различных трафиков ожидают пересылки на удаленные сайты. Запрос закрывается по прошествии некоторого периода отсутствия активности. Обработка запроса обычно представляет собой очень медленный процесс, что делает многопротокольный режим более предпочтительным.
4.20.4 IP в отдельной виртуальной цепи X.25
Если трафик IP пересылается по отдельной коммутируемой виртуальной цепи, то это отражается в пакете Call Request протокола X.25, который инициализирует цепь. В этом пакете имеется необязательное поле Call User Data (вызываемые пользователем данные), которое для указания на трафик IP должно содержать значение X'CC.
Значение X'CC является идентификатором протокола сетевого уровня (Network Layer Protocol ID — NLPID), как это установлено для трафика IP организацией ISO.
4.20.5 Другие протоколы в отдельной виртуальной цепи X.25
Несколько других протоколов также имеют коды ISO для NLPID, но коммерческим лицензионным протоколам такие коды не присвоены. Однако, как можно предположить, многие коммерческие протоколы производят присваивание двухбайтового кода типа для общепринятого многопротокольного окружения — Ethernet. Например, трафик AppleTalk имеет код типа Ethernet со значением X'80-9B.
Для запуска в виртуальной цепи одного протокола с присвоением кода типа Ethernet код NLPID должен иметь значение X'80 со следующим далее подзаголовком SNAP, что указывается в поле Call User Data пакета Call Request протокола X.25. Например, для установки виртуальной цепи на работу с трафиком AppleTalk следует послать:
X'80-00-00-00-80-9B
4.20.6 Многопротокольный режим в виртуальной цепи
Если в виртуальной цепи организуется многопротокольный режим, поле Call User Data устанавливается в X'00 и в каждый кадр добавляется дополнительный заголовок, позволяющий идентифицировать тип протокола. Идентификация датаграммы IP очень эффективно выполняется посредством значения IP NLPID, равного X'CC,— это и будет дополнительным заголовком.
Для протоколов, идентификация которых выполняется кодом типа Ethernet, заголовок сообщения начинается NLPID со значением X'80, что указывает на следующий далее подзаголовок SNAP. Например, для цепи с многопротокольным режимом каждому PDU протокола AppleTalk будет предшествовать заголовок:
X'80-00-00-00-80-9B
4.20.7 Пакеты или PDU?
Существует незначительная сложность в способе пересылки информации по Х.25. Некоторые сети X.25 передают пакеты очень маленького размера. Однако передать весь высокоуровневый PDU (например, датаграмму IP) можно через непрерывную последовательность пакетов (packet sequence) с объединением данных в единый PDU на другой стороне цепи (для этого служит флажок "more/nomore" — еще/больше нет). В этом случае идентификатор протокола требуется только в заголовке первого пакета X.25 из пересылаемой последовательности.
4.21 Frame Relay
Сети X.25 обеспечивают надежную и последовательную пересылку данных. Однако высоки непроизводительные расходы, связанные с качеством обслуживания в этих сетях. Когда трафик IP пересылается потоком по виртуальной цепи X.25, непроизводительные расходы приводят к существенным потерям.
Технология Frame Relay (это протокол уровня 2) более подходит для набора протоколов TCP/IP. В этом случае к датаграмме IP добавляются только заголовок уровня связи данных и завершающая часть для проверки ошибок.
X.25 хранит сообщение до подтверждения его приема и пересылает сообщение повторно, если не получает сигнала подтверждения (ACK). В отличие от X.25 Frame Relay не сохраняет сообщения, не ждет получения ACK и не пересылает данные повторно, что позволяет более эффективно использовать доступную полосу пропускания.
Начальный кадр Frame Relay стандартным способом определяет только службу одной виртуальной цепи. Пользователь должен связаться со службой провайдера и согласовать с ним требуемую скорость передачи при доступе к заданному сайту. Многие провайдеры обеспечивают скорости обмена вплоть до максимальной для линии Т1 скорости в 1.544 Мбит/с. Вне территорий США и Японии доступны линии E1 со скоростью 2.048 Мбит/с. (T1 и E1 отличаются только организациями, принявшими данные стандарты — американским и европейским комитетами соответственно. С технической точки зрения данные стандарты, включая доступные скорости обмена, подобны, хотя и не совместимы полностью между собой. — Прим. пер.) Обычно клиент платит фиксированную месячную арендную плату, величина которой зависит от согласованной скорости обмена.
Коммутируемые службы Frame Relay позволяют системам с присвоенными номерами динамически устанавливать коммуникационные цепи, как при обычном телефонном соединении. Поддержка коммутируемых служб обеспечивает больше возможностей, но заранее трудно предвидеть пользовательский трафик в каждый момент времени, а сети будут работать с перегрузками в случайные моменты.
Frame Relay обеспечивает лучшую производительность по сравнению с X.25 и поэтому чаще применяется на практике. На основе оборудования Frame Relay некоторые организации создают собственные лицензионные системы для внутренних сетей.
Как и для рассмотренных ранее протоколов, комитет IETF специфицировал формат для многопротокольной маршрутизации и перехода трафика через сетевые мосты для совместного использования цепей Frame Relay. Инкапсуляция датаграмм IP представлена на рис. 4.18.
Рис. 4.18. Инкапсуляция датаграммы IP в Frame Relay
Адресное поле Frame Relay обычно имеет длину в 2 октета и содержит 10-битовое поле идентификатора соединения по связи данных (Data Link Connection Identifier — DLCI), определяющее отдельную цепь. Несколько бит в адресном поле используется для наполнения сигналов значениями, когда нужно указать, что кадр должен обрабатываться определенным образом, например для указания отмены кадра во время перегрузки. Если провайдер использует более длинные адреса, можно расширить адресное поле до 3 или 4 октетов.
Поле управления (CTL) имеет значение X'03 (т.е. нечисловая информация). Идентификатор протокола X'CC указывает, что кадр содержит датаграмму IP.
Кадры пересылаются по сети провайдера. Отбрасываются все кадры, проверочная последовательность (FCS) которых указывает на ошибку в них.
Для протоколов, которые должны описываться кодом типа Ethernet (например, AppleTalk), заголовок сообщения имеет формат, показанный на рис. 4.19. Для улучшения выравнивания сообщения после поля управления вставлен добавочный октет-заполнитель X'00. Значение X'80 для NLPID говорит о следующем далее подзаголовке SNAP. В нашем примере он содержит код типа Ethernet для протокола AppleTalk.
Рис. 4.19. Заголовок кадра Frame Relay с кодом типа Ethernet
За исключением байта-заполнителя (pad), данный заголовок идентичен заголовку для цепи X.25 в многопротокольном режиме.
4.22 SMDS
Служба коммутируемых многомегабитных данных (Switched Multimegabit Data Service — SMDS) является еще одной общедоступной службой с коммутацией пакетов. Она была разработана для региональных компаний Bell (в свое время корпорация Bell была разделена правительством США на несколько региональных компаний. — Прим. пер.). Данная служба предназначена для предоставления широкого спектра вариантов производительности, включая высокоскоростные соединения, например 155 Мбит/с.
Интересным свойством SMDS является то, что данные могут быть посланы без открытия виртуальной цепи — без создания соединения (connectionless). На практике логическая подсеть IP может быть сформирована с возможностями региональных сетей, и (см. рис. 4.20) этот логический сегмент региональной сети будет наследовать многие возможности высокоскоростных локальных сетей. Такие свойства делают SMDS привлекательной для создания магистральной структуры региональных сетей.
Рис. 4.20. Магистральная региональная сеть SMDS
Протокол интерфейса SMDS (SMDS Interface Protocol — SIP) основан на стандарте IEEE с номером 802.6.
4.22.1 IP поверх SMDS
Ha рис. 4.21 показан формат заголовка после вставки заголовка SIP SMDS, что отражает факт присутствия датаграммы IP.
Рис. 4.21. Для идентификации IP в SMDS используются LLC и SNAP.
Этот формат подобен используемому в локальных сетях IEEE 802. Первые три октета создают заголовок LLC IEEE 802.2, а содержащий значение X'08-00 подзаголовок SNAP определяет для IP код типа Ethernet.
Служба коммутируемых многомегабитных данных (Switched Multimegabit Data Service — SMDS) является еще одной общедоступной службой с коммутацией пакетов. Она была разработана для региональных компаний Bell (в свое время корпорация Bell была разделена правительством США на несколько региональных компаний. — Прим. пер.). Данная служба предназначена для предоставления широкого спектра вариантов производительности, включая высокоскоростные соединения, например 155 Мбит/с.
Интересным свойством SMDS является то, что данные могут быть посланы без открытия виртуальной цепи — без создания соединения (connectionless). На практике логическая подсеть IP может быть сформирована с возможностями региональных сетей, и (см. рис. 4.20) этот логический сегмент региональной сети будет наследовать многие возможности высокоскоростных локальных сетей. Такие свойства делают SMDS привлекательной для создания магистральной структуры региональных сетей.
Рис. 4.20. Магистральная региональная сеть SMDS
Протокол интерфейса SMDS (SMDS Interface Protocol — SIP) основан на стандарте IEEE с номером 802.6.
4.22.1 IP поверх SMDS
Ha рис. 4.21 показан формат заголовка после вставки заголовка SIP SMDS, что отражает факт присутствия датаграммы IP.
Рис. 4.21. Для идентификации IP в SMDS используются LLC и SNAP.
Этот формат подобен используемому в локальных сетях IEEE 802. Первые три октета создают заголовок LLC IEEE 802.2, а содержащий значение X'08-00 подзаголовок SNAP определяет для IP код типа Ethernet.
4.23 ATM
Режим асинхронной пересылки (Asynchronous Transfer Mode — ATM) представляет собой технологию с коммутацией ячеек, подходящую как для локальных, так и для региональных сетей. ATM объединяет преимущества безопасности при коммутируемом доступе с высокой производительностью и гибкостью. Эту технологию можно характеризовать следующим образом:
■ Данные коммутируются в 53-октетных ячейках.
■ Каждая ячейка имеет пятибайтовый заголовок, содержащий информацию для ее маршрутизации.
■ Кадры разбиваются на ячейки в источнике и вновь объединяются в кадры в точке назначения с помощью уровней адаптации ATM (ATM Adaptation Layer — AAL).
■ Существует несколько AAL, однако к пересылке датаграмм IP имеет отношение только AAL5.
■ Работу по сегментации и последующей сборке кадров при пересылке по региональной сети выполняет интерфейс обмена данными (Data Exchange Interface — DXI) — часть оборудования, соответствующая цифровому интерфейсу обычной телефонной линии.
Как в X.25 или Frame Relay, коммуникации ATM формируются путем создания виртуальной цепи и пересылки кадров по этой цепи.
В сетях ATM существуют два метода обслуживания многопротокольного трафика:
■ Создание отдельной виртуальной цепи для каждого протокола
■ Совместное использование одной виртуальной цепи всеми протоколами
Выбор одного из методов зависит от стоимости, а также от времени установки и закрытия виртуальной цепи.
Если для каждого протокола используется отдельная виртуальная цепь (как в X.25), то тип протокола для коммутируемой цепи можно анонсировать только один раз — в сообщении запроса на вызов.
Когда несколько маршрутизируемых протоколов совместно используют одну виртуальную цепь (см. рис. 4.22), кадр AAL5 начинается с уже известных нам заголовков LLC и SNAP. Тип IP Ethernet заключается в подзаголовке SNAP (см. рис. 4.22).
Рис. 4.22. Для идентификации IP в ATM AAL используются LLC и SNAP.
Отметим, что кадр AAL5 не имеет в заголовке полей с адресами источника и назначения. Дело в том, что после вызова устанавливается виртуальная цепь от источника до точки назначения, а необходимая для коммутации в точке назначения информация находится в 5-октетном заголовке ячейки.
Заключительная часть AAL5 содержит байты-заполнители (для выравнивания), поле данных пользователя, поле payload length (длина полезной нагрузки) и проверочную последовательность кадра (FCS). Полезная нагрузка учитывает размеры заголовков LLC и SNAP и самой датаграммы.
4.24 Максимальное число пересылаемых элементов
Каждая из рассмотренных нами технологий имеет различные максимальные размеры для своих кадров. После исключения заголовка кадра, заключительной части, а также заголовков LLC и SNAP (если они присутствуют), полученный результат будет определять максимально возможный размер датаграммы, которую можно переслать по носителю. Эта величина называется максимальным пересылаемым элементом (Maximum Transmission Unit — MTU).
Например, максимальный размер кадра для сети 802.3 10BASE5 равен 1518 октетам. Вычитая длину MAC-заголовка и завершающей части (18 октетов), поле управления связи Type 1 и заголовок SNAP (8 октетов), мы получим MTU, равный 1492 октетам.
В таблице 4.1 приведены MTU для различных технологий.
Таблица 4.1 Максимальный пересылаемый элемент
| Протокол | Максимальное количество октетов в датаграмме (MTU) |
|---|---|
| По умолчанию для PPP | 1500 |
| PPP (с небольшой задержкой) | 296 |
| SLIP | 1006 (исходное ограничение) |
| X.25 | 1600 (отличается для некоторых сетей) |
| Frame Relay | Обычно не менее 1600 |
| SMDS | 9235 |
| Ethernet версии 2 | 1500 |
| IEEE 802.3/802.2 | 1492 |
| IEEE 802.4/802.2 | 8166 |
| 16 Mb IBM Token-Ring | Максимально 17914 |
| IEEE 802.5/802.2 4-Mb Token-Ring | Максимально 4464 |
| FDDI | 4352 |
| Hyperchannel | 65535 |
| ATM | По умолчанию 9180 Максимально возможно 16K-1 |
Специальным случаем является линия "точка-точка". Она реально не наследует ограничений на размер датаграммы. Оптимальный размер зависит от уровня ошибок в данной линии связи. Если он высок, то лучшая производительность достигается при более коротких элементах данных. Максимальное значение по умолчанию в 1500 байт используется наиболее часто.
Первоначально протокол SLIP был специфицирован с максимальной длиной датаграммы в 1006 байт. Некоторые реализации могут поддерживать до 1500 байт, преобразуя SLIP в другие форматы пересылки данных по последовательной линии "точка-точка".
Для Token-Ring показано предельное значение MTU. Реально MTU для Token-Ring зависит от множества факторов, включая время удержания маркера в кольце.
4.25 Создание туннелей
Всегда придерживаться структуры деления на уровни — хорошая идея, но часто используется более простой способ пересылки данных из одной точки в другую с помощью другого протокола. Такой процесс называется созданием туннеля (tunneling) — возможно, по причине временного скрытия данных в другом протоколе до момента достижения выходной точки туннеля.
Создание туннеля не представляет особых сложностей — просто вокруг элемента данных создается один или несколько дополнительных заголовков, маршрутизация выполняется средствами другого протокола, а извлечение полезной информации происходит в точке назначения.
Мы уже рассматривали применение туннеля. Когда датаграмма IP перемещается по сети X.25, она обрамляется заголовком сетевого уровня X.25. В этом случае трафик IP пересылается через туннель в среде X.25.
На практике применяется множество других вариантов использования туннелей. Иногда трафик IPX операционной системы Novell NetWare пересылается по туннелю в сети IP. Сообщения из NetWare обрамляются заголовками IP или UDP, маршрутизация производится в сети IP, а доставка выполняется на удаленный сервер NetWare. Многие разработчики предлагают продукты для пересылки по туннелю трафика SNA в сети IP.
Туннели всегда приводят к дополнительной нагрузке. Поскольку часть сетевого пути скрыта внутри внешнего протокола, использование туннеля сокращает возможности по управлению и обслуживанию в сети и часто создает дополнительный трафик, не имеющий отношения к пересылке полезной информации.
4.26 Совместное использование сетевого интерфейса
Как уже отмечалось, несложно найти локальные и региональные сети, использующие одновременно несколько протоколов. На практике один сетевой узел иногда посылает и принимает данные по нескольким протоколам через единый сетевой интерфейс.
Чтобы понять, как это происходит, рассмотрим конкретный интерфейс — локальную сеть Ethernet. Если персональный компьютер или сервер станут использовать интерфейс Ethernet для TCP/IP, IPX или DECnet, то как будут сосуществовать эти протоколы?
Мы уже знаем ответ на этот вопрос. Заголовок уровня связи данных содержит поле, идентифицирующее протокол сетевого уровня для конкретного сообщения.
На рис. 4.23 показан интерфейс Ethernet, совместно используемый стеками протоколов TCP/IP, IPX и DECnet. Посредничающий при выполнении операций программный уровень драйверов устройств скрывает действия по вводу/выводу от стеков протоколов более высокого уровня.
Рис. 4.23. Протоколы совместно используют сетевой интерфейс.
4.27 Замечания об уровне связи данных
Доля датаграмм, управляющих информацией, оказывает влияние на общую производительность. Разумеется, когда нужно переслать в сети большой объем данных, лучше заполнять датаграммы как можно плотнее.
Для разных типов сетей максимальные размеры датаграмм различны. В главе 6 мы познакомимся с предоставляемым в IP механизмом фрагментации — разделением больших датаграмм с последующей пересылкой в кадрах с датаграммами меньшего размера. Такая возможность обеспечивает доставку данных, даже если превышается используемый размер MTU. Однако можно предположить, что фрагментация и последующее воссоздание снижают время ответа сети.
Если пара взаимодействующих хостов подключена к одной и той же локальной сети, то желательно оптимизировать пересылку данных за счет использования максимально возможного размера датаграммы. Однако при работе с удаленным хостом через сеть неизвестного типа некоторые реализации принудительно используют меньшее значение для максимального размера датаграммы (иногда 576 октетов), чтобы избежать фрагментации.
Далее мы увидим, что процедура автоматического определения наибольшего размера датаграммы может выполняться для любого заданного пути пересылки данных (глава 7). Оптимизируя размер датаграмм, можно исключить фрагментацию и пересылать большие массивы данных более эффективно.
4.28 Завершающая часть кадра
Некоторые проблемы возникают при использовании нестандартных форматов протоколов из устаревших версий TCP/IP. Реализация BSD 4.2 предоставляет нестандартный формат для MAC-кадров Ethernet, в котором исключено поле типа кадра, а информация заголовков уровней 3 и 4 перемещена в завершающую часть кадра (trailer). Цель этой перестановки — ускорение обработки поступающих кадров за счет снижения количества копирования данных. Такая возможность реализуется в некоторых коммерческих продуктах.
Использование завершающей части кадра в стиле Беркли может привести к несовместимости, но этот вариант становится все более редким на практике. Если все же необходимо воспользоваться этим методом, следует ознакомиться с рекомендациями из RFC 1122 по его безопасному применению.
4.29 Рекомендуемая литература
RFC 1661 описывает протокол PPP. Аутентификация в PPP рассматривается в RFC 1334, а автоматический мониторинг качества линии — в RFC 1333.
Существует несколько RFC, обсуждающих пересылку датаграмм IP поверх средств более низкого уровня: RFC 1356 для X.25, RFC 1490 для Frame Relay, RFC 1209 для SMDS, RFC 1390 для FDDI, RFC 1577, 1932, 1626 и 1755 для ATM, RFC 1088 для NetBIOS, RFC 1055 для SLIP, RFC 1042 для сетей IEEE 802, RFC 894 для Ethernet и RFC 1201 для ARCNET.
Сведения о HDLC можно найти в ISO 3309, 4335 и 7809. Серия IEEE 802 и ISO 8802 описывает физические носители, доступ к носителю, а также протоколы логических связей для локальных и городских сетей.
Рекомендации CCITT по X.25 можно обнаружить в "Красной книге" CCITT 1984 г. Существует несколько документов по стандартам для Frame Relay. Лучше всего начать с ANSI T1.606 и рекомендации CCITT 1.122.
RFC 893 обсуждает инкапсуляцию в завершающей части кадра.
ТЕЛЕГРАМКанал с обзорами, анонсами новинок и книжными подборками
Книжный Вестник
Бот для удобного поиска книг (если не нашлось на сайте)
Поиск книг
Свежие любовные романы в удобных форматах
Любовные романы
О психологии, саморазвитии и личностном росте
Саморазвитие
Детективы и триллеры, все новинки
Детективы
Фантастика и фэнтези, все новинки
Фантастика
Отборные классические книги
Классика
ВКОНТАКТЕБиблиотека с любовными романами, которая наверняка придётся по вкусу женской части аудитории
Любовные романы
Библиотека с фантастикой и фэнтези, а также смежных жанров
Фантастика
Самые популярные книги в формате фб2
Топ фб2
книги