Берри Нанс. Компьютерные сети
Подождите немного. Документ загружается.
(данные уровня LLC). Вам уже известно об уровне LLC, где проходят пакеты,
содержащие данные для прикладных программ, такие как части дисковых
файлов и сообщения межкомпьютерного обмена в ЛВС. Другой уровень -
MAC, отвечает за обработку пакетов сообщений, которыми адаптеры
самостоятельно обмениваются для выполнения функций контроля и
управления работой логического кольца. В стандарте IEEE 802.5 определены
шесть управляющих пакетов уровня MAC. Поле контроля (FC) пакета
определяет тип пакета (MAC или LLC), а также к которому из шести типов (в
случае пакета MAC) он принадлежит. Ниже коротко описаны шесть типов
пакетов MAC:
Тест Дублирования Адреса. Передается рабочей станцией, впервые
присоединяемой к логическому кольцу, чтобы убедиться, что ее адрес является
уникальным.
Присутствие Активного Монитора. Передается активным монитором
достаточно часто для уведомления других рабочих станций о том, что
активный монитор функционирует.
Присутствие Запасного Монитора. Передается запасными
мониторами.
Требование маркера. Если запасной монитор обнаруживает, что
активный монитор перестал функционировать, он приступает к передаче
пакетов с требованием маркера. Запасные мониторы в этом случае начинают
процесс взаимодействия друг с другом, чтобы назначить новый активный
монитор.
Маяк. Передается в случае обнаружения серьезных проблем в ЛВС,
таких как обрыв в кабеле или начало передачи узлом до получения им маркера.
Для локализации проблемы диагностическому программному обеспечению
достаточно определить узел, который передает это сообщение.
Чистка. Передается после инициализации логического кольца и после
установки нового активного монитора.
Каждый пакет (MAC или LLC) начинается со стартовой
последовательности пакета SFS, содержащей три поля:
Начальный Разделитель (SD). Определение такое же, как для маркера.
Контроль доступа (АС). Определение такое же, как для маркера.
Контроль Пакета (FC - Frame Control). Это однобайтовое поле
содержит две области - тип пакета и контрольный код MAC: FF СССССС.
Два бита (FF), определяющие тип пакета, имеют значение 00 для пакета
уровня MAC и 01 для пакета уровня LLC (значения 10 и 11 зарезервированы).
Контрольный код MAC определяет тип управляющего пакета:
СССССС Пакет MAC
000011 Требование маркера
000000 Тест дублирования адреса
000101 Присутствие активного монитора
000110 Присутствие запасного монитора
000010 Маяк
000100 Чистка
Поле адреса назначения (DA) следует непосредственно за полем SFS и 1
может иметь длину 2 или 6 байт. В случае двухбайтового адреса первый бит (I/
G - Individual/Group) является признаком индивидуального или группового
адреса (так же, как в протоколе с обнаружением коллизий по стандарту IEEE
802.3). В случае 6 байтного адреса первый бит также является I/G битом, а
второй определяет глобальное или локальное назначение пакета (U/L бит так
же, как в стандарте IEEE 802.3). Остальные биты определяют адрес узла,
которому данное сообщение предназначено.
Поле адреса источника (SA) имеет такие же размеры и формат, как и поле
адреса назначения.
Поле данных (DATA) может содержать пользовательские данные,
полученные или предназначенные для протоколов среднего уровня, таких как
IPX, TCP/IP или NetBIOS. Поле данных может также содержать один из типов
пакетов уровня MAC, которые были рассмотрены выше. Нет специального
ограничения на длину поля данных, хотя практически оно возникает из-за того,
что допустимое для отдельной рабочей станции время распоряжения сетью
ограничено.
Поле FCS (контрольная сумма) пакета имеет длину 4 байта и содержит
контрольную сумму типа CRC-32. Это поле используется для контроля ошибок.
Поле EFS (конец пакета) состоит из двух областей - концевого
разделителя и статуса пакета.
Концевой разделитель (ED). Вы уже встречались с этим полем при
рассмотрении маркера, однако для пакета оно приобретает дополнительное
значение. Это поле содержит, кроме уникальной последовательности
электрических импульсов, еще две области длиной 1 бит каждая. Бит
промежуточного пакета устанавливается в 1, если данный пакет является
частью многопакетной передачи, и равен 0, когда пакет является последним
(единственным). Бит обнаружения ошибки сбрасывается в 0 в момент создания
пакета в источнике. При прохождении этого сообщения через каждый из
адаптеров в других узлах
В случае обнаружения ошибки бит обнаружения ошибки устанавливается
в 1. После этого при дальнейшем передвижении пакета по ЛВС контроль
ошибок уже не производится, а пакеты ретранслируются до достижения узла
источника, который в этом случае предпримет повторную попытку передачи
пакета.
Статус пакета (FS). Это однобайтовое поле содержит четыре
резервных бита (R) и два внутренних поля: бит распознавания адреса (А) и бит
копирования пакета (С): AC RR AC RR
Так как контрольная сумма не охватывает поле FS, то каждое однобитное
поле в байте задублировано для гарантии достоверности данных, Передающий
узел сбрасывает в нуль биты А - "Адрес распознан" и С - "Данные
скопированы". Приемный узел устанавливает бит "Адрес распознан" в 1 после
получения пакета. Бит "Данные скопированы" устанавливается в 1 приемным
узлом, если не было ошибок при получении данных, после копирования пакета
в буфер. Таким образом, признаком того, что передача произведена успешно
является возвращение пакета к источнику с обеими битами, установленными в
1.
Если же бит А в момент возвращения пакета оказался не установлен в 1,
это означает, что станции-адресата больше нет в сети или другая рабочая
станция вышла из строя (выключена).
Другая ситуация возникает, если бит А в момент возвращения пакета
установлен в 1, но при этом бит С "Данные скопированы" установлен в 0. Это
означает, что произошла ошибка на пути пакета от источника к адресату (при
этом также будет установлен в 1 бит обнаружения ошибки в концевом
разделителе).
И наконец, если установлены в 1 все три бита, то это означает, что
ошибка произошла на обратном пути пакета от адресата к источнику, после
того как пакет был успешно принят.
Последовательность завершения
На рис. 5.11 представлен третий из форматов пакетов сообщений по
стандарту IEEE 802.5 - последовательность завершения. Необходимость в такой
последовательности может возникнуть для прекращения процесса передачи в
любой момент этого процесса.
Код завершения состоит из начального разделителя и следующего за ним
концевого разделителя.
ОПТОВОЛОКОННЫЙ РАСПРЕДЕЛЕННЫЙ ИНТЕРФЕЙС (FDDI)
Оптоволоконный интерфейс распределения данных (FDDI - Fiber
Distributed Data Interface) является гораздо более современным протоколом,
чем Ethernet или Token Ring. Разработанный специалистами группы ХЗТ9.5
института ANSI (American National Standards Institute – Американский
институт стандартов) протокол FDDI работает по схеме передачи маркера в
логическом кольце с оптоволоконными кабелями и имеет производительность
100 Мбит/с. Этот протокол задумывался таким образом, чтобы максимально
соответствовать стандарту IEEE 802.5 Token Ring. Различия имеются только
там, где это необходимо для реализации большей скорости обмена данными и
способности перекрытия больших расстояний передачи.
Рис. 5.11. Последовательность завершения
Так как в FDDI применяется принятый в Token Ring принцип
кодирования битов данных, то для передачи одного бита информации
требовалось бы чередование двух оптических сигналов - импульса света и
паузы. Поэтому для передачи информации со скоростью 100 Мбит/с в этом
случае требовалось бы 200 миллионов сигналов в секунду. Вместо этого в FDDI
используется схема 4В/5В, кодирующая 4 бита данных в пятибитовые
комбинации световых импульсов, таким образом уменьшая число сигналов,
необходимых для передачи одного байта информации. Пятибитовые коды
(символы) были тщательно подобраны по скоростным требованиям сети. Таким
образом, для достижения производительности ЛВС на уровне 100 Мбит/с в
схеме 4В/5В необходима скорость передачи оптических сигналов 125
миллионов сигналов в секунду (125 мегабод). Кроме того, так как в этой схеме
используются символы, представляющие 4 бита (полубайт или ниббл), то
аппаратные средства FDDI могут оперировать с полубайтами или байтами, а не
с битами, тем самым еще более способствуя увеличению скорости обмена.
Существуют два основных отличия в работе с маркером в протоколах
FDDI и IEEE 802.5 Token Ring. B IEEE 802.5 новый маркер передается рабочей
станцией в ЛВС только после возвращения к ней сообщения, которое она
передала в сеть. В FDDI новый маркер будет передан непосредственно после
передачи пакета сообщения. Кроме того, FDDI не использует областей
приоритета и резервирования, которые используются в IEEE 802.5 для
выделения ресурсов системы. Вместо этого в FDDI каждая рабочая станция
классифицируется как асинхронная (которая не предъявляет жестких
требований к интервалам времени, через которые возможен доступ к сети) я
синхронная (которая предъявляет очень жесткие требования по отношению к
интервалам времени между передачами). FDDI использует сложный алгоритм
для предоставления доступа к сети этим двум классам устройств.
На рис. 5.12 представлен маркер FDDI. Маркер состоит из преамбулы,
начального разделителя (SD), контроля пакета (FC), концевого разделителя
(ED) и поля статуса пакета (FS). Эти поля имеют одинаковые определения для
маркеров и пакетов.
Рис. 5.12. Маркер FDDI
На рис. 5.13 представлен пакет FDDI. Отметим сходство между ним и уже
рассмотренным нами пакетом IEEE 802.5. Пакет FDDI также, как его более
медленный собрат, переносит контрольные данные уровня MAC или
пользовательские данные.
Рис. 5.13. Пакет FDDI
Поля в пакете FDDI имеют следующие значения:
Преамбула. Это поле предназначено для синхронизации. Несмотря на
то, что изначально длина этого поля равна 64 бит (16 символьных полубайтов),
узлы могут динамически изменять ее в соответствии со своими требованиями к
синхронизации.
Начальный разделитель (SD). Уникальное двухсимвольное
(однобайтовое) поле, предназначенное для идентификации начала пакета.
Контроль пакета (FC). Двухсимвольное (1 байтовое) поле, состоящее
из следующих областей: С L FF ТТТТ
Бит С устанавливает класс пакета, который определяет, будет ли пакет
использоваться для синхронного или асинхронного обмена. Бит L - индикатор
длины адреса пакета, которая может быть 16 или 48 бит (в отличие от Ethernet и
Token Ring здесь допускается использование в одной сети адресов той и другой
длины). Биты FF (формат пакета) определяют, принадлежит ли пакет
подуровню MAC (т.е. предназначен для целей управления кольцом) или
подуровню LLC (т.е. предназначен для передачи данных). Если пакет является
пакетом подуровня MAC, то биты ТТТТ определяют тип пакета, содержащего
данные в информационном поле (INFO).
Назначение (DA). Это поле может иметь длину 16 или 48 бит и
определяет рабочую станцию, которой предназначен пакет.
Источник (SA). Это поле может иметь длину 16 или 48 бит и
определяет рабочую станцию, передавшую данный пакет.
Информация (INFO). В этом поле содержатся данные. Они могут быть
данными типа MAC, предназначенными для управления кольцом, или данными
пользователя. Длина этого поля является переменной, но ограничена
суммарной длиной пакета, не превосходящей 4500 байт.
Контрольная сумма пакета (FCS). В этом поле длиной 4 байта (8
полубайт) располагается CRC-сумма, используемая для обнаружения ошибок.
Концевой разделитель (ED). Это поле имеет длину полбайта (один
символ) для пакета и байт (два символа) для маркера и предназначено для
однозначной идентификации конца пакета или маркера.
Статус пакета (FS). Это поле произвольной длины и содержит биты
"Обнаружена ошибка", "Адрес опознан", "Данные скопированы". Эти поля
предназначены для тех же функций, что и в Token Ring.
УПРАВЛЕНИЕ СЕТЕВЫМИ АДАПТЕРАМИ ПОСРЕДСТВОМ
СЕТЕВОЙ ОС
Открытый интерфейс связи (ODI - Open Datalink Interface) и
Спецификация интерфейса сетевых драйверов (NDIS - Network Driver Interface
Specification) представляют два конкурирующих стандарта, определяющих
способ управления сетевыми адаптерами посредством сетевой ОС.
ODI
ODI - это совместная разработка фирм Novell и Apple Computer. Она
выполняет функции аналогичные NDIS, однако эти стандарты несовместимы.
Производители адаптеров поставляют программные драйверы,
удовлетворяющие стандарту ODI, для обеспечения совместимости своих
изделий с наиболее популярной сетевой ОС NetWare.
NDIS
NDIS - это совместная разработка фирм Microsoft и 3Com. Она является
краеугольным камнем операционных систем LAN Manager и LAN Server,
Аналогично ODI для обеспечения совместимости адаптеров с ОС их
производителям необходимо поставлять в комплекте с адаптерами
соответствующие программные драйверы.
Нетрудно догадаться, что производители адаптеров снабжают их
программными драйверами для обоих стандартов.
Файл PROTOCOL.INI
Для конфигурирования драйверов стандарта ODI используется файл
NET.CFG, а для драйверов стандарта NDIS - файл PROTOCOL.INI. Формат и
содержимое этих файлов совершенно различно.
Большинство программ, предназначенных для инсталляции сетевых
программных продуктов, автоматически создают файлы PROTOCOL.INI или
(NET.CFG) на рабочей станции и файловом сервере. Однако нередко бывает
нужно изменять эти файлы: увеличивать значения некоторых параметров для
обеспечения возможностей вновь установленных программ управления базами
данных (большее количество сеансов NetBIOS, например) или настраивать
параметры для улучшения производительности ЛВС.
Если вам знакома процедура редактирования файла WIN.INI системы
Windows, то вы не встретите трудностей при редактировании файла
PROTOCOL.INI. Как обычный текстовый файл PROTOCOL.INI состоит из
одного или более поименованных разделов, в каждом из которых содержится
имя протокола или драйвера уровня MAC (Контроль доступа к среде). Имя
раздела заключено в квадратные скобки. Под именем каждого раздела с
небольшим сдвигом от начала строки (обычно на три позиции) располагаются
строки с конфигурационными параметрами в формате имя=значение. Сдвиги в
строках не являются обязательными, а сами строки содержат
конфигурационные параметры или команды для NDIS. Например, один из
разделов файла PROTOCOL.INI может содержать следующие строки:
[XYZNetBIOS]
Drivername = NetBIOS$
Bindings = ETHERFAST
MaxNCBs =16
MaxSessions = 32
MaxNames = 16
Спецификация NDIS допускает только определенный синтаксис строк в
файле PROTOCOL.INI. Поэтому при его модификациях для гарантии того, что
NDIS модуль Protocol Manager (Модуль управления протоколом) и •модули
драйверов NDIS смогут правильно интерпретировать ваши команды,
необходимо придерживаться правил, принятых в спецификации NDIS.
Используемые вами ключевые слова и значения зависят от загружаемых
Драйверов. Поэтому необходимо просмотреть документацию,
сопровождающую сетевой адаптер (с целью обнаружения драйверов MAC) или
сетевую "С (для выяснения имен драйверов протокола).
Как же быть, если полное, исчерпывающее описание параметров драйвера
отсутствует? Можно, конечно, позвонить по телефону в отдел технического
обслуживания поставщика этого продукта. Менее очевидным, но часто
наиболее плодотворным, может оказаться простой просмотр в
шестнадцатиричной форме содержимого файла драйвера. При таком просмотре
можно обнаружить ключевые имена параметров, фигурирующих внутри файла
PROTOCOL.INI. Необходимо также иметь в виду, что NDIS-совместимое
программное обеспечение, инсталлирующее драйверы, обычно использует
файлы NIF (Network Installation File - Сетевые инсталляционные файлы) для
указания того, какие строки могут входить в файл PROTOCOL.INI. Это
программное обеспечение использует NIF для того, чтобы знать, какие
параметры предлагать на выбор в процессе инсталляции. Вы можете
предварительно просмотреть NIF для лучшего понимания параметров драйвера.
Далее приведены правила конструирования файла PROTOCOL.INI:
Имя каждого протокола или модуля MAC должно быть заключено в
квадратные скобки, как [XYZNetBIOS] в предыдущем примере, и должно
содержать не более 15 символов. Можно использовать как заглавные, так и
строчные символы. При чтении этих данных в память программой Protocol
Manager все символы будут преобразованы в заглавные.
Строка Drivername = имя драйвера устройства необходима в
разделах, описывающих модули драйверов устройств. Эта строка определяет
имя файла, который содержит модуль драйвера устройства (OS/2 или DOS).
Каждый сетевой драйвер может запросить у модуля управления протоколом
(Protocol Manager) просмотреть копию файла PROTOCOL.INI, хранящуюся в
памяти. Таким образом сетевой драйвер находит свой раздел модуля по
соответствующей строке Drivername. Спецификация NDIS также требует
наличия строки Drivername для резидентных программ DOS. Даже если
резидентная программа не является драйвером устройства, строка Drivername
позволяет ей найти подходящий раздел в файле PROTOCOL.INI. В некоторых
случаях допускается многократное появление имени драйвера устройства в
файле PROTOCOL.INI. Такое, например, может иметь место в случае, когда
драйвер устройства содержит много логических модулей.
Модули протокола (в отличие от модулей уровня MAC) могут
содержать строку Bindings = имя модуля в INI-файле. Наличие такой строки
является указанием модулю протокола на то, с каким из модулей MAC нужно
быть связанным. Этот параметр может быть использован для реконфигурации
протокола, чтобы связываться с различными модулями MAC,
поддерживаемыми используемым протоколом. В строке Bindings нет
необходимости, если драйвер протокола заранее сконфигурирован под
определенный модуль MAC, или если стек протокола содержит только один
модуль MAC и один статический модуль протокола.
Остальная часть файла PROTOCOL.INI состоит из пар ключе-
вое_слово = значение, с длиной каждого ключевого слова не более 15 символов.
Как уже упомянуто, программа Protocol Manager не различает прописные и
заглавные символы в строках. Пары ключевое_слово = значение относятся
только к тем именованным разделам, в которых они появились. Следует
заметить, что разрешается использование пробелов с обеих сторон знака
равенства для придания файлу более удобного для чтения вида. Программа
Protocol Manager автоматически удалит эти пробелы, а также пробелы,
завершающие строку. Это же относится к символам табуляции и перевода
формата.
В каждой строке с текстом за знаком равенства следуют один или
более параметров. Если строка не имеет параметров, знак равенства является
необязательным. Если имеется много параметров, то они должны быть
разделены пробелами, символами табуляции, запятыми или двоеточиями.
Следует заметить, что программа Protocol Manager не интерпретирует
параметры, а с задаваемыми значениями работает только модуль протокола
уровня MAC. Если параметр является числом, то он интерпретируется как 32-
разрядное число со знаком. Разрешается использовать как десятичные, так и
шестнадцатиричные формы представления чисел, причем шестнадцатиричные
числа должны быть снабжены префиксом Ох или ОХ. Параметр-строка может
быть любой длины. Строка должна начинаться нечисловым символом или быть
заключена в кавычки ("").
Строки, имеющие точку с запятой в первой колонке, считаются
строками комментариев (некоторые инсталлирующие программы вставляют
строки комментариев для того, чтобы можно было разобраться с тем, что они
создали, но это можно сделать впоследствии самим). Программа Protocol
Manager игнорирует комментарии и пустые строки.
При обнаружении синтаксической ошибки в файле PROTOCOL.INI
программой Protocol Manager или одним из драйверов, в спецификации NDIS
предусмотрен вывод диагностических сообщений об ошибках с детализацией
проблемы. Если возможно, то программное обеспечение должно
самостоятельно исправить значение на правильное и продолжить работу. Но на
практике не все драйверы удовлетворяют этим требованиям, так что < иногда
модуль мгновенно "погибает" при обнаружении ошибки в файле
PROTOCOL.INI.
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ ПОДДЕРЖКИ IBM PC LAN
Программное обеспечение IBM PC LAN разработано фирмой IBM для
ЛВС типа Token Ring и ориентировано на работу под управлением DOS. В него
входят программы, поддерживающие адаптеры и NetBIOS, в виде набора
Драйверов устройств (SYS-файлов), которые устанавливаются ОС во время
ГРУЗКИ. Обычно используются три таких драйвера, использующие объем
памяти в зависимости от их конфигурации в диапазоне от 40К до 50К. Из них
файл DXMAOMOD.SYS является арбитром прерываний для адаптера Token
Ring. Он действует как диспетчер, направляя сетевые запросы различным
программным модулям поддержки ЛВС. Драйвер DXMCOMOD.SYS является
уровнем программного обеспечения поддержки адаптера, непосредственно
связанным с набором интегральных схем для Token Ring адаптера. И наконец,
драйвер DXMTOMOD.SYS реализует протокол среднего уровня, NetBIOS.
ПРОТОКОЛЫ СРЕДНЕГО УРОВНЯ
До сих пор рассмотренные протоколы работали на самом низком уровне
ЛВС. Так, протоколы Ethernet, Token Ring и FDDI имеют дело с передачей
сообщений (пакетов) между компьютерами, но ничего не знают о файл-
серверах и перенаправлении файлов. Эти протоколы даже не включают
никаких средств для обеспечения правильной последовательности приема
переданных данных, а также средств для идентификации прикладных
программ, нуждающихся в обмене данными.
Протоколы среднего уровня NetBIOS, IPX/SPX и TCP/IP при
классификации по модели OSI более всего соответствуют транспортному
уровню с некоторыми характеристиками других уровней (таких, как сеансовый
уровень). Эти протоколы позволяют компьютерам в ЛВС легко обмениваться
данными друг с другом.
Протоколы высокого уровня, предназначенные для выполнения функций
перенаправления файлов, используют протоколы среднего уровня для передачи
пакетов сообщений между рабочими станциями и файловым сервером. В
последующих разделах этой главы будет проведено обсуждение протоколов
высокого уровня.
Независимо от внутренней конструкции каждого конкретного протокола,
все они имеют определенные общие функции и свойства:
Инициализация связи. Каждый протокол имеет средства для
идентификации рабочей станции по имени, номеру или по обоим этим
атрибутам. Эта схема идентификации доступна как уровню, где осуществляется
перенаправление файлов, так и прикладной программе. Обмен информацией
между определенными узлами активизируется после идентификации узла-
адресата (обычно файлового сервера) рабочей станцией, инициирующей
диалог. Инициирующая станция также устанавливает один из двух типов
диалога: датаграмму, в которой пакеты адресуются и передаются без гарантии
или подтверждения получения, и сеанс, в котором устанавливается связь с
определенной станцией и гарантируется доставка сообщений.
Отправка и получение данных. Каждый протокол представляет
средства для отправки и получения сообщений рабочими станциями адресата и
источника. Протокол накладывает определенные ограничения на длину
сообщений, кроме того он предоставляет участникам диалога сеансного типа
средства для определения статуса диалога. Например, рабочая станция может
быть неумышленно выключена во время диалога из-за того, что кто-то
выдернул шнур питания. Тогда остальные участники диалога могут выяснить,
что возникла ошибка в сети.
Завершение обмена. Протокол предоставляет средства для вежливого
завершения диалога.
Ниже проводится рассмотрение протоколов IPX, SPX, TCP/IP и NetBIOS-
Данные, циркулирующие в ЛВС, фактически поступают от прикладных
программ или от программного обеспечения для перенаправления файлов»
которые переносят запросы DOS на файловый сервер и обратно.
ДАТАГРАММЫ И СЕАНСЫ