semenov_yu_a_telekommunikacionnye_tehnologii / 207_425
.doc|
С точки зрения службы каталогов netware (NDS - netware directory services) сеть - это не совокупность ЭВМ, а интегрированная информационная среда. При регистрации в сети клиент получает доступ ко всем ее ресурсам. Для повышения надежности и сокращения времени доступа к сети база данных службы каталогов netware распределена по сети. Отдельные фрагменты базы данных могут располагаться на разных серверах, и могут быть задублированы на нескольких серверах, имеются специальные сетевые средства для синхронизации изменений в этих секциях. Все эти вещи порождают в сети дополнительный трафик, ведь необходимо сравнивать содержимое секций базы данных, их обновление, читать и изменять записи и т.д. Одной из важнейших функций службы каталогов является синхронизация работы ее частей. Синхронизация предполагает определение порядка операций по обслуживанию каталога. В службе каталогов все серверы делятся на:
Существует пять функций NCP, которые поддерживают взаимодействие со службой каталогов Netware. Имеются также функции службы каталогов. Коды функций вставляются в пакеты, посылаемые службой каталогов, и служат в качестве субфункций основных NCP-операций. Таблица (4.2.1.5.1) функций и субфункций службы каталогов представлена ниже. Таблица 4.2.1.5.1 Основные NCP-функции
Запрос nds в режиме ping позволяет запросить сервер о поддержке им операции с кодом 104. Если сервер может выполнить эту операцию, он посылает позитивный отклик, который содержит имя дерева каталога и его глубину. При посылке фрагментированного nds запроса присылается фрагментированный отклик. При обновлении секции каталога netware передает последовательность nds-фрагментов, содержащих изменения данной секции. Формат таких пакетов показан на рис. 4.2.1.5.1. В скобках указаны размеры полей в байтах. Поле максимальный размер фрагмента несет в себе максимальное число байт, которое может быть послано в качестве отклика. Код в этом поле соответствует максимуму, поддерживаемому сетевой средой минус 8 (сумма длин поля длины отклика и поля дескриптора фрагмента). Поле флага фрагмента всегда содержит нуль. Поле внутренняя функция хранит в себе код операции для службы каталогов netware. Таблица команд службы каталогов приведена в приложении (10.5) . В netware имеется развитая собственная система сетевой диагностики, которая позволяет выяснить реальную конфигурацию сети (возможно, что-то не включено или уже сломалось), ее загруженность или частоту ошибок (diagnostic responder). Узлы сети с загруженной программой diagnostic responder должны откликаться на диагностические пакеты, адресованные им или разосланные широковещательно. Наличие отклика говорит о доступности данного сетевого объекта, а его содержимое может нести в себе информацию о конфигурации (наличие IPX/SPX, драйвера локальной сети, программы маршрутизатора или файлового сервера).
Рис. 4.2.1.5.1. Формат пакетов рагментированный NDS-запрос/отклик> Диагностические запросы содержат код 0x0456 в поле соединителя получателя IPX-заголовка. Формат такого запроса показан на рис. 4.2.1.5.2. Однобайтовое поле счетчика исключаемых узлов задает число станций, которые могут не присылать отклик. Нуль в этом поле предполагает, что все станции должны откликнуться. Допустимый диапазон значений кодов в этом поле 0 - 79. При широковещательной рассылке запроса можно сделать так, чтобы сервер и определенные клиенты на запрос не реагировали. Для этого их адреса помещаются в поля адресов исключаемых узлов. Число таких исключений может достигать 80.
Рис. 4.2.1.5.2. Формат диагностического запроса Структура пакета-отклика показана на рис. 4.2.1.5.3. В зависимости от числа компонентов конфигурации пакет-отклик может иметь различную длину. Поля базового и вспомогательного номера версии характеризуют вариант программы diagnostic responder (например, 1.1). Поле номер диагностического соединителя SPX указывает на соединитель, которому отсылаются все диагностические отклики. Поле счетчик компонентов содержит число описаний компонентов, содержащихся в пакете. Поле тип компонента описывает один из компонентов (или процессов) узла, посылающего отклик. Описание компонента может быть простым и расширенным. Простое описание содержит один байт идентификатора компонента. Расширенное описание компонента включает в себя информацию о маршрутизаторах, файл-серверах и невыделенных IPX/SPX. Первое поле в этом случае представляет собой идентификатор расширенного описания, который характеризует тип компонента: Таблица 4.2.1.5.1. Коды типа компонентов
Далее следует поле числа локальных сетей, характеризующее количество сетей, обменивающееся данными с данным компонентом. Для каждой из сетей указывается ее тип, а также адрес сети и узла. Поле типа сети содержит код типа (таблица 4.2.1.5.2). Таблица 4.2.1.5.2 Коды типа сети
Поле адреса сети имеет 4 байта, а поле адреса узла 6 байт, перенаправленные удаленные линии имеют адрес узла 0x00-00-00-00-00-00. Внутренние сети IPX версий 3.x и 4.x имеют адрес узла 0x00-00-00-00-00-01.
Рис. 4.2.1.5.3 Формат пакета диагностического отклика Сервера Novell за счет протоколов RIP и SAP могут заметно загрузить локальную сеть широковещательными сообщениями. По этой причине не следует бездумно множить число таких серверов. |
|
4.2.2 AppleTalk |
|
Сеть APPLETALK разработана компанией apple computer inc. (ЭВМ Macintosh, 1987 г) Эти сети могут работать в среде Ethernet, Token Ring, FDDI и localtalk (собственная сеть apple, использующая скрученные пары). В AppleTalk специфицирован собственный стек протоколов, которые управляют потоком данных в сети. Для целей маршрутизации AppleTalk использует модифицированную версию внутреннего протокола маршрутизации IGRP. Стек протоколов appletalk phase ii включает в себя (схема структуры стека протоколов показана на рис. 4.2.2.1; смотри http://bbs-win.uniinc.msk.ru/product/bay/routers/protocol, а также RFC-1378, -1419, -1504, -1742):
Из рисунка 4.2.2.1 видно, что стек протоколов appletalk полностью согласуется с семиуровневой схемой OSI. DDP представляет собой протокол передачи данных, не ориентированный на соединение. Дейтограмма DDP использует 13-байтовый заголовок, который включает в себя: поле числа маршрутизаторов (число шагов), через которые прошел пакет; поле длины дейтограммы; поле контрольной суммы; поля сети назначения и отправителя и т.д. (см. рис. 4.2.2.2. - смотри http://www.stanford.edu/group/networking/adminatalk/atalk_3.html). Вслед за заголовком следует информация, которая может содержать до 586 байт. Максимальный размер пакета (MTU) равен 599 байтам. Число узлов в сети может достигать 16 миллионов.
Рис. 4.2.2.1. Диаграмма стека протоколов appletalk Протокол adsp позволяет двум программам обмениваться потоками информации в полном дуплексном режиме с гарантией доставки. Протоколы TLAP, ELAP и LLAP служат для обеспечения сопряжения с соответствующими физическими протоколами (Token Ring, Ethernet и Arcnet), скрывая от программ других уровней специфические особенности используемого сетевого оборудования. Протокол ATP надежно передает запросы и отклики, детектирует ошибки и организует пакетный обмен. Этот протокол используется в свою очередь протоколами ZIP, ASP и PAP, что видно из рис. 4.2.2.1. Протокол AFP является протоколом поддержки приложений и позволяет пользователям ЭВМ Macintosh работать с общими файлами. Программное обеспечение Netware для Macintosh включает в себя файл AFP NLMtm, который обеспечивает поддержку Netware-серверов. Протокол AURP (appletalk update-based routing protocol) служит для целей маршрутизации, но в отличии от некоторых других протоколов передает маршрутную информацию только в случае изменения ситуации. Он поддерживает также IP-туннели.
Рис. 4.2.2.2. Формат пакетов в сети Apple Talk Phase II (в скобках указаны размеры полей в байтах) Адрес отправителя и получателя имеют по 24 бита, из них 16 бит составляет адрес сети. Идентификатор узла назначения (локальная часть адреса) выбирается произвольно самой рабочей станции при установлении связи. ЭВМ берет случайное 8-битовое число в качестве локального адреса и посылает его в сеть. Если какая-то ЭВМ использует этот адрес, она откликается, тогда код меняется и делается повторная попытка. Процесс продолжается пока не будет найден свободный адрес. Протокол RTMP является протоколом маршрутизации, где в качестве метрики используется вектор расстояния до адресата, этот протокол собирает маршрутную информацию и предоставляет ее протоколу DDP для обеспечения транспортировки пакетов по сети. Маршрутные таблицы RTMP хранятся в каждом из маршрутизаторов AppleTalk и базируются на номерах сетей адресатов. Таблица содержит в себе расстояние до адресата, измеренное в шагах (hop), идентификатор порта маршрутизатора, через который достижим адресат, и статус маршрута. Маршрутизаторы AppleTalk формируют и актуализируют маршрутные таблицы, посылая регулярно (раз в 10 сек) широковещательные RTMP-пакеты соседним узлам и сетям. Запись в маршрутной таблице, своевременно не подтвержденная, спустя определенное время стирается. Записи в маршрутной таблице попадают в разряд одозреваемыхри отсутствии отклика от них в течение 20 сек, в разряд мирающихспустя 40 сек, в категорию мершихчерез 60 сек. Запись удаляется из таблицы, если отклик не удается получить в течение 80 сек. Адреса сетевого уровня ставятся в соответствие адресам MAC-уровня с помощью адресного протокола AARP. Узлы сети Apple Talk хранят эту информацию в специальных таблицах (AMT - Address Mapping Table). Таблица просматривается всякий раз, когда AppleTalk посылает пакет. Если поиск не увенчался успехом, узел-отправитель посылает широковещательный AARP-запрос. При получении отклика на этот запрос вносятся коррективы в AMT-таблицу. Особенностью сети AppleTalk является согласование при присвоении локальных адресов объектам сети. При инициализации узла ему присваивается временный адрес. Протокол AARP проверяет, не принадлежит ли данный адрес кому-то еще, для этого он посылает 10 AARP-запросов. Если данный временный адрес уже используется, инициализируемому узлу присваивается новый временный адрес и процедура проверки повторяется до тех пор, пока узлу не будет присвоен уникальный адрес. Протокол NBP преобразует локальные AppleTalk адреса в имена, присвоенные сетевому объекту пользователем и наоборот. Это избавляет пользователя от необходимости помнить полный сетевой адрес принт- или файл-сервера, почтового сервера и т.д.. Протокол ZIP допускает логическое группирование оконечных сетевых узлов в некоторые объединения, называемые зонами, что позволяет ЭВМ, принадлежащие к одному отделу, но расположенные в разных зданиях, находиться в одной зоне (субсети). Зона может представлять собой комбинацию локальных сетей, а в случае EtherTalk Phase II - часть локальной сети. Информация о зонах хранится в маршрутизаторах в виде специальных таблиц (ZIT - Zone Information Table). Таблица содержит по одной записи на сетевой сегмент. Запись включает в себя номер сетевого сегмента и список объектов, входящих в зону. Протокол ZIP отслеживает изменения в RTMP-таблицах и при появлении в них записей, относящихся к новым объектам или сетям, маршрутизатор посылает ZIP -запрос и на основе полученной информации корректирует ZIT-таблицу. Протокол AEP выполняет отладочные и диагностические функции, предоставляя возможность выполнения процедур ping (до какой-то степени это аналог протокола ICMP). При необходимости проверить состояние сети или какого-либо узла посылается AEP-дейтограмма, а зондируемый узел, который при ее получении должен послать отклик отправителю исходного запроса. Протокол позволяет проверить время распространения пакетов между узлами сети. Протокол может использоваться в начале любой сессии для проверки доступности того или иного сетевого объекта. Протокол AURP является внешним протоколом сетевой маршрутизации и служит для взаимодействия сетей AppleTalk c Интернет. Протокол поддерживает технологию IP-туннелей с использованием UDP/IP инкапсуляции. Рассылка сетевой информации осуществляется AURP только при возникновении каких-либо изменений в состоянии сети. Протокол AURP поддерживает гибкую систему переадресаций, исключая конфликты адресов при подключении новых сетей AppleTalk, и выявляет маршрутные петли. Существуют специальные фильтры, которые позволяют разделять пакеты по приоритетам, что бывает важно, например, при передаче мультимедиа информации. Сети AppleTalk хорошо согласуются с другими сетями, например, NetWare. Следует иметь в виду, что ЭВМ, работающие с протоколами Phase I и Phase II, могут работать друг с другом только через специальные мосты, так как форматы пакетов для этих протоколов не совместимы. Управление сетями Apple Talk осуществляется с помощью протокола SNMP и управляющей базы данных MIB. |
|
4.2.3 NetBIOS |
||||||||||||||||||
|
Протокол NetBIOS был создан для работы в локальных сетях. Система NetBIOS предназначена для персональных ЭВМ типа IBM/PC в качестве интерфейса, независящего от фирмы-производителя. NetBIOS использует в качестве транспортных протоколов TCP и UDP. Описание NetBIOS содержится в документе IBM 6322916 "Technical Reference PC Network" (см. также RFC-1001-2, -1088 и STD-48). Пакет NETBIOS (см. также ftp://ietf.org/internet-drafts/draft-ietf-pppext-netbios-fcp-08.txt) создан для использования группой ЭВМ, поддерживает как режим сессий (работа через соединение), так и режим дейтограмм (без установления соединения). 16-и символьные имена объектов в netbios распределяются динамически. netbios имеет собственную dns, которая может взаимодействовать с интернетовской. Имя объекта при работе с NETBIOS не может начинаться с символа *. Приложения могут через netbios найти нужные им ресурсы, установить связь и послать или получить информацию. NETBIOS использует для службы имен порт - 137, для службы дейтограмм - порт 138, а для сессий - порт 139. Любая сессия начинается с netbios-запроса, задания ip-адреса и определения tcp-порта удаленного объекта, далее следует обмен NETBIOS-сообщениями, после чего сессия закрывается. Сессия осуществляет обмен информацией между двумя netbios-приложениями. Длина сообщения лежит в пределах от 0 до 131071 байт. Допустимо одновременное осуществление нескольких сессий между двумя объектами. При организации IP-транспорта через NETBIOS IP-дейтограмма вкладывается в NETBIOS-пакет. Информационный обмен происходит в этом случае без установления связи между объектами. Имена Netbios должны содержать в себе IP-адреса. Так часть NETBIOS-адреса может иметь вид, ip.**.**.**.**, где IP указывает на тип операции (IP через Netbios), а **.**.**.** - ip-адрес. Система netbios имеет собственную систему команд (call, listen, hang up, send, receive, session status, reset, cancel, adapter status, unlink, remote program load) и примитивов для работы с дейтограммами (send datagram, send broadcast datagram, receive datagram, receive broadcast datagram). Все оконечные узлы netbios делятся на три типа:
IP-адрес может ассоциироваться с одним из указанных типов. B-узлы устанавливают связь со своим партнером посредством широковещательных запросов. P- и M-узлы для этой цели используют netbios сервер имен (NBNS) и сервер распределения дейтограмм (NBDD). В настоящее время (1985 г) разработана улучшенная версия протокола NETBIOS - NetBeui (NetBios extended user interface). Этот новый протокол используется операционными системами LAN manager, LAN server, Windows for Workgroups и Windows NT, а по своей функции занимает нишу протоколов TCP/IP, охватывая связной, сетевой и транспортный уровни. Здесь стандартизован формат пакетов NetBios, добавлены некоторые новые функции. netbuei базируется на протоколе OSI LLC2, вводит стандарт на формат кадра netbios (NDF) и использует NetBios в качестве интерфейса высокого уровня. Протокол обладает высоким быстродействием и служит для объединения небольших локальных сетей (20-200 ЭВМ) друг с другом или с главной ЭВМ. Этот протокол соответствует связному, сетевому и транспортному уровню модели OSI. В новых версиях NetBuei (3.0 и выше) снято ограничение на число одновременных сессий (254). Среди ограничений NetBuei следует назвать отсутствие внутренней маршрутизации и серьезные ограничения при работе в региональных сетях. По этой причине netbuei рекомендуется для локальных сетей (здесь они предпочтительнее других протоколов), а для внешних связей использовать, например, TCP/IP. Для подключения терминальной системы к локальной сети или к другой терминальной системе разработан протокол NBFCP (NetBios frames control protocol, код поля протокола = 803F), который в свою очередь базируется на протоколе PPP. Формат кадра протокола NBFCP показан на рис. 4.2.3.1.
Рис. 4.2.3.1. Формат кадра NBFCP Поле тип содержит код 2, поле длина определяет размер заголовка, если длина=8, имя партнера отсутствует. Поле класс партнера идентифицирует тип системы отправителя (см. таблицу 4.2.3.1). Таблица возможных значений поля класс партнера приведена ниже. Поле имя партнера может иметь до 32 октетов. Таблица 4.2.3.1 Коды класса партнера
|
|
4.3 Региональные сети |
||||||||||||||||||
Региональные сети (WAN - Wide Area Network) с точки зрения архитектуры и протоколов практически не отличаются от глобальных. В региональных сетях обычно не используются трансокеанские кабели, но это отличие не может рассматриваться как принципиальное. Региональные сети решают проблему формирования из LAN (локальных сетей) сетей регионов и целых стран и даже наднациональных сетей (например, E-BONE для Европы). Как правило, эти сети строятся с использованием протоколов SDH, ATM, ISDN, Frame Relay или X.25. Архитектурно такие сети формируются из каналов со схемой точка-точка и мощных коммутаторов-мультиплексоров. Из таких фрагментов формируются и опорные сети (BackBone), которые позволяют сократить число шагов от узла к узлу. В этих сетях в основном используются оптоволоконные транспортные системы, а там где это нерентабельно, спутниковые или радиорелейные каналы. С появлением корпоративных сетей типа Интранет понятия локальной и региональной сетей стало частично перекрываться. Для пользователя Интранет все узлы такой сети являются локальными, хотя и могут отстоять на сотни или даже тысячи километров друг от друга. По существу сети Интранет являются наложенными сетями по отношению к региональным сетям (WAN). Интернет также следует отнести к числу наложенных сетей по отношению к WAN. |