Подходы к интеграции неоднородных сетей

Источники и типы неоднородностей в транспортной подсистеме

Использование различных базовых сетевых технологий

Базовая сетевая технология - это согласованный набор протоколов и реализующих их программно-аппаратных средств, достаточный для построения вычислительной сети. Протоколы, на основе которых строится сеть базовой технологии, специально разрабатывались для с овместной работы, поэтому от разработчика сети не требуется дополнительных усилий по организации их взаимодействия. Примерами базовых сетевых технологий могут служить хорошо известные технологии Ethernet и Token Ring для локальных сетей и технологии Х.25 и frame relay для территориальных сетей. Для получения работоспособной сети в этом случае достаточно приобрести программные и аппаратные средства, относящиеся к одной базовой технологии - сетевые адаптеры с драйверами, концентраторы, коммутаторы, кабельну ю систему и т.п., и соединить их в соответствии с требованиями стандарта на данную технологию.

Однако, построение крупной сети на основе одной базовой технологии - это большая редкость. Обычным состоянием для любой вычислительной сети средних и крупных размеров является сосуществование различных стандартов и базовых технологий. Появление новых техн ологий, таких как Fast Ethernet или 100VG-AnyLAN, не означает, что мгновенно исчезают старые, например, 10-Мегабитный Ethernet, Token Ring или FDDI, так как в эти технологии были сделаны огромные капиталовложения. Поэтому трудно рассчитывать на вытеснение в обозримом будущем всех технологий какой-либо одной, хотя бы и такой многообещающей, как ATM.

Степень неоднородности сетевых технологий существенно возрастает при необходимости объединения локальных и глобальных сетей, имеющих, как правило, существенно различные стеки протоколов. Хотя в последние годы и наметилась тенденция к сближению методов пер едачи данных, используемых в этих двух типах вычислительных сетей, различия между ними все еще велики. Поэтому в пределах одной корпоративной сети обычно используется большой набор разнообразных базовых топологий и задача объединения их всех в единую сеть , прозрачную для транспортных операций конечных узлов, требует привлечения специальных методов и средств.

Использование нескольких протоколов сетевого уровня (IP, IPX, X.25)

Самым распространенным средством объединения разнородных транспортных технологий является использование единого сетевого протокола во всех узлах корпоративной сети. Единый сетевой протокол работает поверх протоколов базовых технологий и является тем общим стержнем, который их объединяет. Именно на основе общего сетевого протокола маршрутизаторы осуществляют передачу данных между сетями, даже в случае очень существенных различий между их базовыми сетевыми технологиями.

Хотя идея объединения составной сети с помощью маршрутизаторов подразумевает использование во всех частях сети одного сетевого протокола, очень часто сетевым интеграторам и администраторам приходится сталкиваться с задачей объединения сетей, каждая из кот орых уже работает на основе своего сетевого протокола. Имеется несколько сетевых протоколов, которые получили широкое распространение: IP, IPX, DECnet, Banyan IP, AppleTalk. Каждый из них имеет свою нишу и своих сторонников, поэтому очень вероятно, что в отдельных частях большой сети будут использоваться разные сетевые протоколы. Маршрутизаторы, даже многопротокольные, не могут решить задачу совместной работы сетей, использующих разные сетевые протоколы, поэтому в таких случаях используются другие средств а, например, программные шлюзы.

Комбинирование разных протоколов сбора маршрутной информации (RIP, OSPF, NLSP)

Маршрутизаторы строят свои адресные таблицы с помощью специальных служебных протоколов, которые обычно называют протоколами обмена маршрутной информации или протоколами маршрутизации.

Протоколы обмена маршрутной информацией также существуют не в единственном числе. Во-первых, протокол обмена маршрутной информацией тесно связан с определенным протоколом сетевого уровня, так как он должен отражать способ адресации сетей и узлов, принятый в этом сетевом протоколе. Поэтому для каждого сетевого протокола должен использоваться свой протокол обмена маршрутной информации. Во-вторых, для каждого сетевого протокола разработано несколько протоколов обмена маршрутной информацией, отличающихся спос обом построения таблицы маршрутизации.

В результате в корпоративной сети может одновременно работать несколько протоколов обмена маршрутной информации, например, RIP IP, RIP IPX, OSPF, NLSP, IGRP. Для того, чтобы добиться их согласованной работы, от администратора сети требуется использование соответствующих маршрутизаторов и выполнения специфических операций по их настройке.

Несовместимость оборудования разных производителей

Проблемы несовместимости оборудования разных производителей, возникают чаще всего по трем причинам:

  • неточная (с ошибками) реализация стандартов;
  • использование фирменных стандартов;
  • улучшение стандартов - введение дополнительных функций и свойств.

Для компаний, являющихся лидерами рынка коммуникационного оборудования, ошибочная реализация стандартов - событие маловероятное, так как их представители всегда составляют основу комитетов, разрабатывающих стандарты.

Однако оставшиеся две причины часто порождают проблемы. На первый взгляд может показаться, что нет ничего страшного в том, что в коммуникационной аппаратуре имеются дополнительные функции или что эта аппаратура поддерживает наряду с общепринятыми и свои, фирменные протоколы. В любом случае остается возможность организовать совместную работу двух устройств разных производителей на основе стандартных протоколов. Тем не менее, на практике этой возможностью удается воспользоваться не всегда. Примером служит и стория с протоколом DLSw, первая стандартная версия которого была описана в документе RFC 1434. Затем компания Cisco выпустила фирменную улучшенную версию этого протокола, названную ею DLSw+, обратно совместимую со стандартной версией. Затем появилась нов ая стандартная версия DLSw, описанная в RFC 1795, которая также была обратно совместима с прежним стандартом. Однако, версия DLSw по RFC 1795 оказалась несовместимой с версией DLSw+, что породило необходимость модификации программного обеспечения в маршру тизаторах Cisco в тех организациях, которые стали устанавливать новые маршрутизаторы от других фирм.

Использование фирменных стандартов может приводить и к тому, что администраторы сетей в какой-то момент при очередной модернизации сети оказываются перед нелегким выбором - либо устанавливать новое оборудование только от одного производителя, даже если ес ть более подходящие варианты, либо переконфигурировать все установленное оборудование для работы по стандартному протоколу, чтобы оно стало совместимо с оборудованием других производителей. Понятно, что каждый из этих вариантов является мало привлекательн ым.

Стратегии межсетевого взаимодействия

Средства взаимодействия компьютеров в сети организованы в виде многоуровневой структуры - стека протоколов. В однородной сети все компьютеры используют один и тот же стек. В контексте межсетевого взаимодействия понятие "сеть" можно определить ка к совокупность компьютеров, общающихся друг с другом с помощью единого стека протоколов. Проблема возникает тогда, когда требуется организовать взаимодействие компьютеров, принадлежащих разным сетям (в указанном выше смысле), то есть организовать взаимоде йствие компьютеров, на которых установлены разные стеки коммуникационных протоколов.

Задачи устранения неоднородности имеют некоторую специфику в зависимости от того, к какому уровню модели OSI (информация о модели OSI приведена в приложении) они относятся, и даже имеют разные названия. Задача объединения транспортных подсистем, отвечающи х только за передачу сообщений, обычно называется internetworking.

Несколько другая проблема, называемая interoperability, возникает при объединении сетей, использующих разные протоколы более высоких уровней. Как сделать, например, возможным для клиентов сети Novell NetWare доступ к файловому сервису Windows NT ил и работу с сервисом telnet ОС Unix?

Очевидно, что подобные проблемы весьма характерны для корпоративных сетей, где в разных подразделениях часто работают разные сетевые операционные системы.

Проблема межсетевого взаимодействия может иметь разные внешние проявления, но суть ее одна - несовпадение используемых коммуникационных протоколов. (Подробнее о стеках коммуникационных протоколов читайте в приложении.) Например, эта проблема возникает в с ети, в которой используется только одна сетевая ОС, но в которой транспортная подсистема неоднородна из-за того, что сеть включает в себя фрагменты Ethernet, объединенные кольцом FDDI. Здесь в качестве взаимодействующих сетей выступают группы компьютеров, использующие различные протоколы канального и физического уровня, например, сеть Ethernet, сеть FDDI.

Равным образом проблема межсетевого взаимодействия может возникнуть в однородной сети Ethernet, в которой установлено несколько сетевых ОС. В этом случае, все компьютеры и все приложения используют для транспортировки сообщений один и тот же набор протоко лов, но взаимодействие клиентских и серверных частей сетевых сервисов осуществляется по разным протоколам. Здесь компьютеры могут быть отнесены к разным сетям, если у них различаются протоколы верхних уровней, например, сеть Windows NT, сеть NetWare. Коне чно, эти сети могут спокойно сосуществовать, не мешая друг другу и мирно пользуясь общим транспортом. Однако, если потребуется обеспечить доступ к данным файл-сервера NetWare для клиентов Windows NT, администратор сети столкнется в необходимостью согласов ания сетевых сервисов.

Существует три основных подхода к согласованию разных стеков протоколов:

  • трансляция;
  • мультиплексирование;
  • инкапсуляция.

Трансляция протоколов

Трансляция обеспечивает согласование двух протоколов путем преобразования (трансля-
ции) сообщений, поступающих от одной сети, в формат другой сети. Транслирующий элемент в качестве которого могут выступать, например, программный или аппаратный шлюз, мост, коммутатор или маршрутизатор, размещается между взаимодействующими сетями и служит посредником в их "диалоге" (рисунок 1.1).

В зависимости от типа транслируемых протоколов процедура трансляции может иметь разную степень сложности. Так, преобразование протокола Ethernet в протокол Token Ring сводится к нескольким несложным действиям, главным образом благодаря тому, что в обоих п ротоколах используется единая адресация узлов. А вот трансляция протоколов сетевого уровня IP и IPX представляет собой гораздо более сложный, интеллектуальный процесс, включающий не только преобразование форматов сообщений, но и отображение адресов сетей и узлов, различным образом трактуемых в этих протоколах.

Рис. 1.1. Пример трансляции протоколов

Следует отметить, что сложность трансляции зависит не от того, насколько высокому уровню соответствуют транслируемые протоколы, а от того, насколько сильно они различаются. Так, например, весьма сложной представляется трансляция протоколов канального уров ня ATM-Ethernet, именно поэтому для их согласования используется не трансляция, а другие подходы.

К частному случаю трансляции протоколов может быть отнесен широко применяемый подход с использованием общего протокола сетевого уровня (IP или IPX). Заголовок сетевого уровня несет информацию, которая, дополняя информацию заголовка канального уровня, позв оляет выполнять преобразование протоколов канального уровня. Процедура трансляции в данном случае выполняется маршрутизаторами, причем помимо информации, содержащейся в заголовках транслируемых кадров, то есть в заголовках канального уровня, дополнительно используется информация более высокого уровня, извлекаемая из заголовков сетевого уровня.

Трансляцию протоколов могут выполнять различные устройства - мосты, коммутаторы, маршрутизаторы, программные и аппаратные шлюзы. Часто транслятор протоколов называют шлюзом в широком смысле, независимо от того, какие протоколы он транслирует. В этом случа е подчеркивается тот факт, что трансляция осуществляется выделенным устройством, соединяющим две разнородные сети.

Мультиплексирование протоколов

Другим подходом к согласованию коммуникационных протоколов является технология мультиплексирования. Этот подход состоит в установке нескольких дополнительных стеков протоколов на одной из конечных машин, участвующих во взаимодействии (рисунок 1.2). Компью тер с несколькими стеками протоколов использует для взаимодействия с другим компьютером тот стек, который понимает этот компьютер.

Для того, чтобы запрос от прикладного процесса был правильно обработан и направлен через соответствующий стек, необходимо наличие специального программного элемента - мультиплексора протоколов. Мультиплексор должен уметь определять, к какой сети на правляется запрос клиента.

При использовании технологии мультиплексирования структура коммуникационных средств операционной системы может быть и более сложной: мультиплексирование осуществляется не на уровне стеков, а на уровне отдельных протоколов. В общем случае на каждом уровне может быть установлено несколько протоколов, и для каждого уровня может существовать собственный мультиплексор, выполняющий коммутацию между протоколами соседних уровней. Например, рабочая станция может получить доступ к сетям с протоколами NetBIOS, IP, I PX через один сетевой адаптер. Аналогично сервер, поддерживающий прикладные протоколы NCP, SMB и NFS может без проблем выполнять запросы рабочих станций сетей NetWare, Windows NT и Sun одновременно.

Рис. 1.2. Мультиплексирование протоколов

Сравнение трансляции и мультиплексирования

Использование техники трансляции связано со следующими достоинствами:

  • Не требуется устанавливать дополнительное программное обеспечение на рабочих станциях.
  • Сохраняется привычная среда пользователей и приложений, транслятор полностью прозрачен для них.
  • Все проблемы межсетевого взаимодействия локализованы, следовательно упрощается администрирование, поиск неисправностей, обеспечение безопасности.

Недостатки согласования протоколов путем трансляции состоят в том, что:

  • Транслятор замедляет работу из-за относительно больших временных затрат на сложную процедуру трансляции, а также из-за ожидания запросов в очередях к единственному элементу, через который проходит весь межсетевой трафик.
  • Централизация обслуживания запросов к "чужой" сети снижает надежность. Однако можно предусмотреть резервирование - использовать несколько трансляторов.
  • При увеличении числа пользователей и интенсивности обращений к ресурсам другой сети резко снижается производительность - плохая масштабируемость.

Достоинства мультиплексирования по сравнению с трансляцией протоколов заключаются в следующем:

  • Запросы выполняются быстрее, за счет отсутствия очередей к единственному межсетевому устройству и использования более простой, чем трансляция, процедуры переключения на нужный протокол.
  • Более надежный способ - при отказе стека на одном из компьютеров доступ к ресурсам другой сети возможен посредством протоколов, установленных на других компьютерах.

Недостатки данного подхода:

  • Сложнее осуществляется администрирование и контроль доступа.
  • Высокая избыточность требует дополнительных ресурсов от рабочих станций, особенно если требуется установить несколько стеков для доступа к нескольким сетям.
  • Менее удобен для пользователей по сравнению с транслятором, так как требует навыков работы с транспортными протоколами "чужих" сетей.

Инкапсуляция (туннелирование) протоколов

Инкапсуляция (encapsulation) или туннелирование (tunneling) - это еще один метод решения задачи согласования сетей, который однако применим только для согласования транспортных протоколов и только при определенных ограничениях. Инкапсуляци может быть использована, когда две сети с одной транспортной технологией необходимо соединить через сеть, использующую другую транспортную технологию. В приведенном на рисунке 1.3 примере две сети с протоколом NetBIOS нужно соединить через сеть TCP/IP. Не обходимо обеспечить только взаимодействие узлов двух сетей NetBIOS, а взаимодействие между узлами NetBIOS и узлами сети TCP/IP не предусматривается. То есть, при инкапсуляции промежуточная сеть используется только как транзитная транспортная система.

Рис. 1.3. Инкапсуляция протоколов сетевого уровня (вложение друг в друга)

Метод инкапсуляции заключается в том, что пограничные маршрутизаторы, которые подключают объединяемые сети к транзитной, упаковывают пакеты транспортного протокола объединяемых сетей в пакеты транспортного протокола транзитной сети. В данном случае пакеты NetBIOS упаковываются в пакеты TCP, как если бы пакеты NetBIOS представляли собой сообщения протокола прикладного уровня. Затем пакеты NetBIOS переносятся по сети TCP/IP до другого пограничного маршрутизатора. Второй пограничный маршрутизатор выполняет о братную операцию - он извлекает пакеты NetBIOS из пакетов TCP и отправляет их по сети назначения адресату.

Для реализации метода инкапсуляции пограничные маршрутизаторы должны быть соответствующим образом сконфигурированы. Они должны знать, во-первых, IP-адреса друг друга, во-вторых - NetBIOS-имена узлов объединяемых сетей. Имея такую информацию, они могут при нять решение о том, какие NetBIOS-пакеты нужно переправить через транзитную сеть, какой IP-адрес указать в пакете, передаваемом через транзитную сеть и каким образом доставить NetBIOS-пакет узлу назначения в конечной сети.

Инкапсуляция может быть использована для транспортных протоколов любого уровня. Например, протокол сетевого уровня Х.25 может быть инкапсулирован в протокол транспортного уровня TCP, или же протокол сетевого уровня IP может быть инкапсулирован в протокол сетевого уровня Х.25. Для согласования сетей на сетевом уровне могут быть использованы многопротокольные и инкапсулирующие маршрутизаторы, а также программные и аппаратные шлюзы.

Обычно инкапсуляция приводит к более простым и быстрым решениям по сравнению с трансляцией, так как решает более частную задачу, не обеспечивая взаимодействия с узлами транзитной сети.

Оглавление | Следующая глава

Back Home E-mail

Copyright © CIT


Средства согласования сетей на сетевом уровне

Шлюзы как средство трансляции сетевых протоколов

Если в разных частях составной сети используются разные сетевые протоколы, то для того, чтобы она функционировала как единая сеть, все узлы которой имели бы возможность обмениваться информацией, может быть использован стандартный прием - трансляция.

Трансляция сетевых протоколов является более сложной задачей, чем трансляция канальных протоколов, хотя бы потому, что в отличие от канального уровня, на котором имеется единая система уникальных адресов узлов, каждый сетевой протокол имеет собственный, с войственный только ему, формат адресов. Кроме различий в системе адресации, в каждом сетевом протоколе имеется еще много других специфических особенностей, которые могут выражаться в различии как количественных параметров (например, для разных протоколов могут быть определены разные величины тайм-аутов, времен жизни пакета или максимальных размеров пакетов), так и в структуре пакетов. Протоколы могут отличаться и функциональными возможностями, например, одни из них реализованы с установлением соединений, а другие - без установления соединений, в одних - предусмотрена возможность фрагментации, в других - нет.

Все эти специфические особенности делают задачу трансляции сетевых протоколов нетривиальной, требующей привлечения программных средств. Устройство, реализующее трансляцию одного сетевого протокола в другой, называется шлюзом. (Некоторые шлюзы решают и бол ее сложную задачу согласования стеков протоколов, включающих протоколы всех уровней.)

Шлюз чаще всего представляет собой программный продукт, устанавливаемый на универсальном компьютере, в таком случае он называется программным шлюзом. Существуют шлюзы, реализованные на специализированной аппаратной платформе, они называются аппаратными шл юзами.

Поддержка нескольких независимых сетей с помощью многопротокольных маршрутизаторов

При наличии многопротокольных маршрутизаторов, то есть таких маршрутизаторов, которые одновременно могут обрабатывать пакеты с различными сетевыми заголовками, и конечных узлов, которые поддерживают тот или иной протокол, интерсеть представляет собой сово купность непересекающихся интерсетей, использующих общие каналы связи и общие кадры канального уровня, но никак не взаимодействующих между собой.

На рисунке 3.1 схематически показан маршрутизатор, поддерживающий два сетевых протокола IP и IPX. При конфигурации маршрутизатора должна быть определена принадлежность каждого его порта к той или иной сети. Каждому порту должен быть присвоен адрес соответ ствующей сети. Очевидно, что все узлы присоединяемые к некоторому порту относятся к сети, назначенной для этого порта.

Трафик, порождаемый узлами, которые принадлежат разным сетям, не смешивается, и влияние сетей друг на друга выражается только тем, что они разделяют общий маршрутизатор и каналы связи, а значит могут взаимно ограничивать доступную им пропускную способност ь линий связи.

Рис. 3.1. Мультипротокольные сети - сети с несколькими сетевыми протоколами

Вполне допустима ситуация, когда один и тот же порт относится к разным сетям и имеет два сетевых адреса. Тогда компьютеры, выходящие на такой порт, могут принадлежать как одной, так и другой сети. Очевидно, что для каждого сетевого протокола конечный узел будет адресоваться оригинальным способом. Так, для протокола IP у него будет один номер сети и узла, а для протокола IPX это будет совсем другая пара чисел. Для того, чтобы иметь возможность получать и отправлять пакеты обоих типов (в данном примере IP и IPX), конечный узел должен поддерживать мультиплексирование протоколов сетевого уровня.

Мультиплексирование протоколов в конечных узлах

При наличии многопротокольных конечных узлов, даже в отсутствие шлюзов, образуется общая интерсеть, если конечные узлы принимают и понимают сетевые пакеты разных типов.

Мультиплексирование протоколов в конечных узлах может осуществляться на нескольких уровнях, обычно это уровни канальных протоколов (называемый также уровнем драйверов сетевых адаптеров), сетевых протоколов (этот уровень часто называют транспортным) и прик ладных протоколов (уровень сетевых сервисов).

Для того, чтобы один сетевой протокол мог использовать несколько канальных протоколов, реализованных в виде драйверов сетевых адаптеров, и, наоборот - один драйвер сетевого адаптера мог работать с несколькими сетевыми протоколами, необходимо стандартизова ть интерфейс между этими уровнями. Примерами таких стандартных интерфейсов и их программных реализаций являются NDIS (Network Driver Interface Specification) и ODI (Open Driver Interface). Эти продукты выполняют не только функции мультиплекс оров, но и функции программной среды, изолирующей драйверы сетевых адаптеров от аппаратуры, то есть самих сетевых адаптеров. NDIS, например. Предоставляет разработчику драйвера функции управления сетевым адаптером, например, функции ввода-вывода, или обра ботки прерываний. Что делает код драйвера более мобильным.

Аналогичные соображения можно привести в пользу стандартизации интерфейса уровней сетевых и прикладных протоколов. Стандартный интерфейс позволяет не только осуществлять произвольные связи между протоколами двух соседних уровней, но и предоставляет разраб отчикам приложений доступ к различным протоколам транспортного уровня, обеспечивая тем самым совместимость приложений.

В большинстве современных сетей конечные узлы и маршрутизаторы почти всегда поддерживают несколько протоколов сетевого уровня, что облегчает построение гетерогенных сетей. Чем больше протоколов сетевого уровня поддерживает маршрутизатор, тем лучше он подх одит для использования в корпоративной сети.

В зависимости от типа маршрутизатора, его роли в сети, он может обладать различными возможностями работы в многопротокольной среде. Практика применения маршрутизаторов разделяет их по областям применения на три класса:

  • Магистральные маршрутизаторы (backbone routers) предназначены для построения центральной сети корпорации и соединения ее с помощью магистральных высокоскоростных и многопротокольных связей с сетями региональных отделений корпораций.
  • Маршрутизаторы региональных отделений - соединяют региональные отделения между собой и с центральной сетью. Сеть регионального отделения, также как и центральная сеть, может состоять из нескольких локальных сетей.
  • Маршрутизаторы удаленных офисов - соединяют, как правило, единственную локальную сеть удаленного офиса с центральной сетью или сетью регионального отделения.

Магистральный маршрутизатор должен поддерживать большой список сетевых протоколов и протоколов маршрутизации, чтобы поддерживать трафик всех существующих на предприятии вычислительных систем (в том числе и морально устаревших, но все еще успешно эксплуати рующихся), а также систем, которые могут появиться на предприятии в ближайшем будущем. Если центральная сеть связывается с региональными отделениями через Internet, то, возможно, потребуется поддержка и специфических протоколов маршрутизации этой сети, та ких как EGP и BGP. Программное обеспечение магистральных маршрутизаторов обычно строится по модульному принципу, поэтому при возникновении потребности можно докупать и добавлять модули, реализующие недостающие протоколы. Перечень поддерживаемых сетевых пр отоколов обычно включает протоколы: IP, CONS и CLNS OSI, IPX, AppleTalk, DECnet, Banyan VINES, Xerox XNS, а перечень протоколов маршрутизации - IP RIP, IPX RIP, NLSP, OSPF, IS-IS OSI, EGP, BGP, VINES RTP, AppleTalk RTMP.

Маршрутизаторы удаленных офисов поддерживают один-два протокола локальных сетей и низкоскоростные глобальные сервисы.

Маршрутизаторы региональных отделений занимают промежуточное положение, и поэтому их иногда не выделяют в отдельный класс устройств.

Наряду с функцией маршрутизации, интеллектуальные маршрутизаторы могут установить приоритеты для различных протоколов сетевого уровня. Это бывает полезно в случае недостаточной полосы пропускания кабельной системы и существования трафика, чувствительного к временным задержкам, например, трафика SNA.

Инкапсуляция на сетевом уровне: X.25 поверх TCP, IPX поверх IP

Метод инкапсуляции часто применяется, когда двум сетям, использующим один и тот же сетевой протокол, нужно связаться через транзитную сеть, которая работает с другими сетевыми протоколами. Примером могут служить две сети Х.25, которым нужно связаться межд у собой через сеть TCP/IP.

В таких случаях сетевой протокол транзитной сети считается протоколом более низкого уровня, чем сетевой протокол объединяемых сетей (рисунок 3.2). Поэтому пакеты сетевого протокола сопрягаемых сетей Х.25 инкапсулируются в пакеты TCP транспортного уровня т ранзитной сети TCP/IP пограничным маршрутизатором М1, и переносятся в пакетах TCP по транзитной сети до следующего пограничного маршрутизатора М2. Для переноса по сети TCP/IP пакеты TCP в соответствии с технологией этой сети помещаются в пакеты IP, которы е инкапсулируются в кадры протокола канального уровня, например, РРР. Пограничный маршрутизатор М2 извлекает пакет Х.25 из пакета TCP и отправляет его по сети Х.25 в соответствии с правилами этого протокола - то есть предварительно установив виртуальное с оединение с узлом назначения по адресу Х.25_S1, а затем отправив по этому виртуальному соединению прибывший пакет.

Рис. 3.2. Соединение сетей X.25 через транзитную сеть TCP/IP методом инкапсуляции

Реализация такого подхода требует от протокола сетевого уровня объединяемых сетей разработанных процедур нахождения адреса пограничного маршрутизатора М2 в транзитной сети TCP/IP по адресу сети назначения протокола Х.25. Обычно такие протоколы называют пр отоколами разрешения адресов - Address Resolution Protocol, ARP. Если бы такой протокол был определен для сети Х.25, то он бы должен оперировать с ARP-таблицей, подобно той, которая приведена на рисунке 3.2. Эта таблица содержит для каждого адреса сети на значения Х.25 соответствующий IP-адрес пограничного маршрутизатора, через который эту сеть можно достичь.

К сожалению, многие сетевые протоколы разрабатывались или в расчете на работу только в сетях своего стека протоколов ( например, протокол Х.25), или в расчете на работу только через локальные сети (например, протокол IPX).

Наибольшую гибкость при инкапсуляции своих пакетов в пакеты других сетевых протоколов демонстрирует протокол IP. Для него разработано семейство протоколов ARP, каждый из которых предназначен для выполнения процедуры инкапсуляции пакетов IP в определенный протокол - Ethernet, Х.25, frame relay, ATM и т.п.

Протокол Х.25 рассчитан на инкапсуляцию только в кадры протокола LAP-B, который в свою очередь передает эти кадры между соседними коммутаторами, соединенными выделенными каналами "точка-точка". Процедуры и таблицы нахождения локальных адресов со седних коммутаторов при передачах пакетов Х.25 не предусмотрены, так как в них нет надобности, если трафик не выходит за пределы сети Х.25. Поэтому для передачи пакетов Х.25 через сети с другим стеком протоколов процедуры разрешения адресов и форматы инка псуляции необходимо определять отельным стандартом.

Похожая ситуация возникает при необходимости передачи пакетов протокола IPX через сети TCP/IP. Процедуры передачи пакетов через составные локальные сети в протоколе IPX предусмотрены. Однако, из-за того, что в протоколе IPX на сетевом уровне для задания а дреса узла просто дублируется аппаратный адрес сетевого адаптера, процедуры отображения сетевого адреса узла на локальные адреса транзитных сетей здесь отсутствуют. Поэтому, для протокола IPX, как и для протокола Х.25, необходимо разработать дополнительны й протокол для того, чтобы этот протокол мог использовать сети TCP/IP как транзитные.

Спецификация "cisco Systems X.25 over TCP (XOT)"

Стандартный способ для передачи трафика сетей Х.25 через сети TCP/IP предусмотрен в спецификации RFC 1613, имеющей название "cisco Systems X.25 over TCP (XOT)", разработанный сотрудниками компании cisco Systems и организации JANET.

Эта спецификация определяет способ инкапсуляции пакетов Х.25 в сообщения TCP для переноса их по магистральной сети TCP/IP.

Так как протокол Х.25 работает на основе установления соединения, то спецификация использует для инкапсуляции протокол TCP, который также работает с установлением соединения. Для каждого виртуального соединения Х.25 маршрутизатор, который поддерживает ста ндарт XOT, устанавливает отдельное TCP-соединение с другим пограничным маршрутизатором. Новое TCP-соединение устанавливается при поступлении из сети Х.25 служебного кадра Call Request, запрашивающего новое соединение и несущего Х.25-адрес узла назначения. Спецификация XOT не предусматривает какого-либо способа определения IP-адреса маршрутизатора-партнера по сети IP, поэтому наиболее целесообразно использовать ее для случая, когда такой партнер один, или же маршрутизатор должен иметь таблицу соответстви адресов Х.25 и IP-адресов маршрутизаторов-партнеров, сформированную вручную.

После установления TCP-соединения все пакеты Х.25, принадлежащие данному виртуальному соединению сети Х.25, передаются в сообщениях TCP, принадлежащих этому TCP-соединению. Так как протокол TCP ориентирован на передачу неструктурированного потока байт, то стандарт ХОТ имеет небольшой заголовок, состоящий из 4-х байт, для выделения пакетов Х.25 в потоке байт сообщений TCP.

Спецификация "Tunneling IPX Traffic through IP Networks"

Для туннелирования пакетов IPX через магистрали TCP/IP компания Novell предложила спецификацию "Tunneling IPX Traffic through IP Networks", которая была утверждена в качестве стандарта RFC 1234.

Спецификация использует инкапсуляцию пакетов IPX в пакеты протокола UDP. Это объясняется тем, что протокол IPX является дейтаграммным протоколом, поэтому удобнее для его транспортировки использовать также дейтаграммный протокол UDP.

Транзитная IP-сеть вместе с объединяемыми IPX сетями рассматривается в этой спецификации как одна IPX-сеть, поэтому узлы по разные стороны IP-сети должны иметь один и тот же сетевой IPХ-адрес.

Спецификация RFC 1234 предлагает автоматизировать процесс поиска маршрутизатора-партнера в сети IP за счет прямого преобразования МАС-адреса узла на фиктивный IP-адрес этого же узла. Адрес узла в приходящем для транзитной передачи IPX-пакете состоит из 6 байт. Для получения IP-адреса назначения пакета, который будет переносить данный IPX-пакет, старшие два байта адреса узла отбрасываются, а оставшиеся 4 рассматриваются как IP-адрес.

Пограничный IP-маршрутизатор должен иметь в своей таблице маршрутизации все IP-адреса узлов сети-партнера IPX, и для этих адресов должен быть указан в качестве IP-адреса следующего маршрутизатора IP-адрес пограничного маршрутизатора с другой стороны транз итной сети. IP-адреса узлов должны иметь маску 255.255.255.255, чтобы номер узла рассматривался как номер сети. В этом случае эти произвольные IP-адреса не будут конфликтовать с легальными номерами сетей в Internet.

Широковещательные пакеты сервиса SAP предлагается распространять на индивидуальной основе, то есть путем дублирования пакета всем узлам сети IPX через сеть IP.

Примеры многопротокольных и инкапсулирующих маршрутизаторов

Мост/маршрутизатор NETBuilder II компании 3Com

Мост/маршрутизатор NETBuilder II предназначен для соединения больших, многосегментных локальных сетей с сетевой магистралью. Его внутренняя шина имеет пропускную способность 800 Мб/с и в сочетании с мультипроцессорной RISC-архитектурой обеспечивает быстры й обмен пакетами между портами во всех режимах работы. Можно менять конфигурацию устройства не останавливая его работы - это обеспечивается за счет соответствующей программной поддержки процесса конфигурирования.

Имеется несколько вариантов шасси для NETBuilder II - на 4 слота, на 8 слотов и расширенное шасси на 8 слотов. В слоты шасси устанавливаются модули двух размеров - обычного и расширенного. В шасси на 4 и на 8 слотов имеются слоты для обычных модулей и слоты для расширенных модулей, причем в расширенный слот можно установить два обычных модуля. Расширенное шасси отличается тем, что в нем пара соседних обычных слотов образует один слот для расширенного модуля, поэтому его компоновка отличаетс большей гибкостью, чем у обычного шасси. Все модули подходят для любого варианта шасси.

Основную работу по ведению топологической базы данных и вычислению маршрутов ведет модуль Communications Engine Card (CEC), то есть модуль коммуникационного центра. Кроме этого, он выполняет и функции управления, включая диагностику с использование м специального диагностического процессора. Высокая скорость вычисления маршрутов обеспечивается за счет наличия в модуле специализированной БИС, работающей совместно с RISC-процессором AMD 29000. CEC выпускается в двух вариантах - с быстрой памятью объем ом 12 Мбайт и объемом 20 Мбайт. Наличие модуля CEC в шасси обязательно.

Модуль CEC совместно с шиной 800 Мб/с обеспечивает скорость продвижения 75000 пакетов в секунду. Дальнейшее повышение производительности маршрутизатора происходит при использовании мультипроцессорной схемы обработки маршрутов, когда каждый интерфейсный мо дуль маршрутизатора имеет свой процессор, работающий в кооперации с модулем CEC. Такой интеллектуальный интерфейсный модуль кэширует информацию о необходимых для его работы маршрутах и обращается к центральному модулю CEC только при отсутствии сведений о новом маршруте. Использование мультипроцессорной архитектуры повышает скорость продвижения пакетов в модуле до 250000. Пока для маршрутизатора NETBuilder II выпускается только один интерфейсный модуль в мультипроцессорной архитектуре - это модуль NETBuild er II MP Ethernet 6-Port 10Base-T. Компания 3Com намерена реализовать в мультипроцессорной архитектуре интерфейсные модули для всех сетевых технологий.

NETBuilder II можно сконфигурировать так, чтобы он работал как мост. В качестве моста он поддерживает такие дополнительные функции, как защиту от широковещательных штормов, алгоритм покрывающего дерева, маршрутизацию от источника (Source rout bridging) и прозрачную маршрутизацию от источника (Source rout transparent bridging). Поддерживаются виртуальные группы, которые затем могут маршрутизироваться на внутренней шине NETBuilder II, образуя виртуальные сети.

В зависимости от используемых шасси и модулей NETBuilder II может поддерживать до 48 локальных связей и до 24 глобальных связей.

Для поддержки глобальных связей имеются модули с интерфейсами V.35, RS-232, RS-449, RS-530, G.703, X.21 и HSSI. Для глобальных связей поддерживаются скорости от 1200 б/с до скоростей T1/E1 и дробных линий T3/E3 (до 6.2 Мб/с), а с модулем HSSI - полные ско рости T3/E3, а также SONET OC-1 (52 Мб/с). Модуль G.703 имеет встроенное устройство DSU/CSU. Интерфейсные модули для глобальных связей могут работать с сетями на основе стандартов PPP, X.25, frame relay, SMDS и ATM.

Для локальных связей имеются модули с портами:

  • Ethernet AUI (1 порт в модуле), BNC (1), 10Base-FL (2), 10Base-T (6);
  • Token Ring DB-9 или RJ-45 (1 порт по выбору);
  • FDDI с поддержкой многомодового или одномодового кабеля, возможно SAS или DAS подключение одного MAC-адреса.

Поддерживаются основные маршрутизируемые протоколы сетевого уровня, включая TCP/IP, Novell IPX, XNS, OSI, DECnet, VINES, AppleTalk, DLSw, APPN. Могут использоваться такие протоколы обмена маршрутной информацией, как RIP-IP, RIP-IPX, OSPF, IS-IS и Novell N LSP.

Для передачи пакетов по глобальным связям может осуществляться компрессия с коэффициентом сжатия до 1:4.

Для работы по коммутируемым телефонным линиям поддерживаются различные стратегии вызова абонента - коммутация по протоколу PPP, вызов по требованию, возможность использования небольшого количества модемов или терминальных адаптеров ISDN для обслуживания б ольшого количества удаленных точек, возможность использования резервной линии для увеличения пропускной способности в случае увеличения трафика или отказа основной линии, вызов абонента по расписанию.

Для управления и администрирования моста/маршрутизатора NETBuilder II может использоваться система управления Transcend в средах Windows и UNIX.

Так как мост/маршрутизатор NETBuilder II представляет собой в высокой степени программируемое устройство, то набор функций, которые он может выполнять по отношению к своим портам и линиям связи, во многом зависит от состава загруженного в его память прогр аммного обеспечения. Версия программного обеспечения NETBuilder II 8.1 состоит из отдельных модулей: моста, центрального маршрутизатора в архитектуре Boundary Routing, IP (вместе с RIP, OSPF, EGP, BGP), IPX (вместе с NLSP), XNS, PPP, компрессии данных, се рвисов вызова по телефонным коммутируемым линиям, поддержки мультипроцессорной архитектуры.

На рисунке 3.3 показан пример построения сети с использованием маршрутизатора NETBuilder II и основных моделей коммутаторов компании 3Com.

Для расширения возможностей NETBuilder II по построению глобальных связей через цифровые телефонные сети ISDN компания 3Com выпустила два устройства расширения: NETBuilder II WAN Extender T1 и E1. Это отдельные устройства в архитектуре Super Stack, которые работают в качестве дополнительного ISDN-интерфейса для моста/маршрутизатора NETBuilder II. Эти устройства обеспечивают большое количество 64-килобитных каналов как для коммутируемых, так и для выделенных цифровых линий. Каждый такой канал данных представляет собой независимый коммуникационный путь к мосту/маршрутизатору в удаленной точке, и он представляется для NETBuilder II как отдельный "виртуальный" порт.

Рис. 3.3.

Устройство NETBuilder II WAN Extender E1 обеспечивает два интерфейса E1, которые независимо присоединяются к каналу ISDN PRI (30 каналов типа B и один канал типа D) или к каналу E1 (31 канал по 64 Кб/с). Поддерживается до 75 виртуальных портов и до 256 уд аленных точек.

Семейство маршрутизаторов компании Bay Networks/Wellfleet

Это семейство состоит из моделей, разработанных для удовлетворения потребностей в объединении сетей самых разных размеров и технологий.

Модели Access Node (AN) и Access Node Hub (ANH) представляют собой недорогое решение для небольших удаленных офисов, имеющих локальные сети Ethernet или Token Ring и нуждающихся в связи с корпоративной магистральной сетью. Модель AN может по ддерживать как Ethernet, так и Token Ring, в то время как модель ANH предназначена для соединения только сетей Ethernet.

Access Stack Node (ASN) - это первый в промышленности стековый маршрутизатор, с помощью которого можно строить легко расширяемые сети, включающие сегменты Ethernet, Token Ring и FDDI, связанные с центральной сетью через глобальные связи. По мере роста сети в стек можно добавлять дополнительные устройства ASN (до 4-х), обеспечивая до 24 сетевых интерфейсов в стеке с общей скоростью продвижения пакетов до 200000 пакетов в секунду.

Модель Backbone Link Node (BLN) предназначена для крупных сетей за счет поддержки до 16 сетевых интерфейсов (Ethernet, Token Ring, FDDI, WAN) с общей производительностью продвижения пакетов 250000 пакетов в секунду.

Разработанный для наиболее ответственных применений, маршрутизатор старшей модели Backbone Concentrator Node (BCN) поддерживает до 52 сетевых интерфейсов с общей производительностью до 760000 пакетов в секунду.

Почти все модели маршрутизаторов (кроме AN и ANH) основаны на симметричной мультипроцессорной архитектуре Wellfleet, которая иллюстрируется рисунком 3.4.

Рис. 3.4. Симметричная мультипроцессорная структура маршрутизаторов Wellfleet

Эта архитектура основана на элементах трех типов: процессорных модулях, модулях связи и высокоскоростной шине межпроцессорных соединений.

Модуль связи (Link module) является интерфейсным модулем, поддерживающим специфический стандартный сетевой интерфейс локальных или глобальных связей (Ethernet, FDDI, RS-232, T1 и т.д.). Каждый модуль связи непосредственно соединен с обслуживающим е го процессорным модулем через специальный интерфейс Processor-Link. Модуль связи выполняет три основные функции:

  • физический интерфейс к специфической сети (Ethernet, Token Ring, ...),
  • передачу пакета через интерфейс Processor-Link в процессорный модуль,
  • фильтрацию пакетов по алгоритму моста, разгружающую процессорный модуль от обработки ненужных пакетов.

Процессорный модуль FRE (Fast Routing Engine) состоит из центрального процессора Motorola MC68040 33MHz, локальной памяти, глобальной памяти (общим объемом 8 Мб), процессора прямого доступа к памяти (DMA) и интерфейса с модулем связи (рисуно к 3.5).

Рис. 3.5. Структура процессорного модул
(интеллектуальный интерфейс модуля связи с процессорным модулем)

Центральный процессор принимает решения по фильтрации/продвижению пакетов, модифицирует заголовки пакетов, если это необходимо, передает пакеты непосредственно присоединенному модулю связи или другому процессорному модулю, обновляет базу данных адресной и топологической информации, поддерживает SNMP-управление и выполняет другую административную работу.

Локальная память хранит маршрутные и адресные таблицы, а также другие данные, которые используются или были выработаны процессором данного модуля.

Глобальная память представляет собой буфер, который хранит пакеты, передаваемые от модуля связи данного процессорного модуля или от другого процессорного модуля. Память называется глобальной, так как она видна из любого процессорного модуля и доступна ему . Пакеты передаются в глобальную память с помощью процессора прямого доступа к памяти (DMA processor).

Процессорные модули поддерживают все основные сетевые протоколы: TCP/IP, OSI, DECnet Phase IV, Novell IPX, Banyan VINES, AppleTalk Phase 2, IBM SNA, X.25, Frame Relay, SMDS, ATM.

Высокоскоростная шина межпроцессорных соединений PPX (Parallel Packet Express) обеспечивает скорость передачи данных 1 Гб/с. Используется 4 независимых, избыточных шины 256 Мб/с, нагрузка между которыми может балансироваться динамически. Шина обесп ечивает высокую производительность и одновременно высокую отказоустойчивость. Каждый процессорный модуль подсоединен ко всем четырем шинам и может выбирать любую для передачи данных (рисунок 3.6). Определенная шина выбирается случайным образ ом для каждого пакета отдельно. Если одна из шин отказывает, то нагрузка перераспределяется между остальными.

Программное обеспечение маршрутизаторов Wellfleet имеет распределенную архитектуру (рисунок 3.7).

Рис. 3.6. Связь процессорных модулей по шине PPX

Функции продвижения пакетов, их фильтрации и управления маршрутизатором распределены по симметричной схеме между процессорными модулями маршрутизатора. Это обеспечивает высокую производительность и отказоустойчивость, так как при отказе одного из процессо рных модулей остальные продолжают выполнять свои функции.

Вся обработка пакетов для интерфейсного модуля выполняется присоединенным к нему процессорным модулем. Каждый процессорный модуль имеет свою копию программного обеспечения, выполняющего функции моста и маршрутизатора, а также свои таблицы маршрутизации. П ри получении пакетов с обновленной маршрутной информацией все вычисления новых значений таблиц маршрутизации выполняются на одном процессорном модуле, а затем эти пакеты передаются остальным процессорным модулям для обработки.

Рис. 3.7. Распределенная архитектура программных средств

Рис. 3.8. Многоуровневая структура программных средств

Исключения делаются только для протоколов, требующих интенсивных вычислений, таких как OSPF. Программный модуль OSPF активизируется только на одном процессорном модуле, который находит оптимальные маршруты, а затем распространяет их по всем процессорным м одулям.

Программное обеспечение маршрутизаторов Wellfleet организовано в соответствии с многоуровневым принципом, как и любая современная операционная система (рисунок 3.8), что позволяет ее легко модифицировать.

Интерфейсные модули (модули связи)

Существует 5 типов интерфейсных модулей связи:

  • Ethernet Intelligent Link Interface - 2/4 порта Ethernet с возможностью высокоскоростной фильтрации (29000 п/с), поддержкой алгоритмов Transparent Bridging и Spanning Tree, конфигурирование с помощью системы Optivity;
  • Token Ring Intelligent Link Interface - 2/4 порта Token Ring 4/16 Мб/с;
  • FDDI Intelligent Link Interface - 2 порта, поддерживающие два соединения SAS или одно соединение DAS, фильтрация со скоростью до 500000 п/с;
  • ATM Intelligent Link Interface - обеспечивает маршрутизаторы BLN и BCN возможностями соединения локальных сетей через частные или общественные сети ATM. Предоставляет мультипротокольные возможности для ATM-рабочих групп. Поддерживает спецификации RFC- 1483 и RFC-1577, определяющие работу протокола IP через сети ATM. Обеспечивает интерфейс SONET/SDH со скоростью 155 Мб/с, поддерживая до 1024 виртуальных каналов SVC. Поддерживает сервис для уровней AAL 3/4 и AAL 5. Для других маршрутизаторов интерфейс с сетями ATM обеспечивается модулями глобальных связей;
  • Serial Intelligent Link Interface - обеспечивают глобальные связи для всех основных видов глобальных интерфейсов и протоколов: V.35, RS-449/422, RS-232, X.21 со скоростью до 6 Мб/с, HSSI для связи с линиями T3/E3 со скоростью до 52 Мб/с; поддерживаютс я протоколы Frame Relay, SMDS и ATM, T1/E1 со скоростью до 2.048 Мб/с, ISDN BRI и PRI.

Маршрутизаторы компании Cisco

Маршрутизаторы, выпускаемые компанией Cisco, можно разделить на следующие классы:

  • Модульные маршрутизаторы. Сюда входят маршрутизаторы, предназначенные для построения магистралей крупных сетей и работающие практически со всеми технологиями локальных и глобальных сетей и со всеми основными сетевыми протоколами: серии Cisco 7500, 700 0, AGS+, Cisco 4000;
  • Маршрутизаторы с фиксированным числом портов, предназначенные для объединения сетей небольших офисов: серии Cisco 3000, Cisco 2500;
  • Маршрутизаторы для подключения тупиковой удаленной локальной сети - "расшири- тели" сетей (LAN extenders): серия Cisco 1000;
  • Маршрутизаторы, встраиваемые в персональные компьютеры - карты AccessPro PC представляют собой полнофункциональные многопротокольные маршрутизаторы, которые устанавливаются в IBM-совместимые персональные компьютеры с шинами ISA или EISA;
  • Серверы доступа компании Cisco предназначены для обеспечения доступа в сеть удаленных пользователей и синхронной/асинхронной маршрутизации; также эти устройства могут функционировать в качестве терминального сервера, сервера удаленного узла, транслято ра протоколов, маршрутизатора.

Модульные маршрутизаторы предоставляют возможность строить систему, выбирая необходимые интерфейсные модули. Количество модулей ограничено размером шасси. Все маршрутизаторы работают под управлением IOS. Модульные маршрутизаторы компании Cisco вклю чают следующие модели: Cisco 7500, Cisco 7000, AGS+, Cisco 4000.

Серия Cisco 7000 поддерживает очень широкий диапазон соединений, среди которых: Ethernet, Token Ring, FDDI, Serial, HSSI, ATM, Channelized T1, Fractionalized E1 (G.703/G.704), ISDN PRI, Channel Interface for IBM mainframes.

Сетевые интерфейсы располагаются на модульных процессорах, которые обеспечивают прямое соединение между высокоскоростной магистралью Cisco Extended Bus (CxBus) и внешней сетью. Пять разъемов доступны под интерфейсные процессоры в модели Cisco 7000. Возмож ность "горячей" замены позволяет добавлять, заменять или удалять процессорные модули CxBus без прерывания работы сети. Для хранения информации используется стандартная Flash-память. Все модели поставляются с комплектом для монтажа в стандартную 19" с тойку. Cisco 7000 содержит пять слотов для интерфейсных процессоров.

Распределенная обработка выполняется процессором маршрутизации (Route Processor - RP), коммутирующим процессором (Switch Processor - SP) и силиконовым коммутирующим процессором (Silicon Switch Processor - SSP).

Протоколы конкретных локальных и глобальных сетей обеспечиваются соответствующими интерфейсными процессорами :

  • Ethernet Interface Processor (EIP),
  • Token Ring Interface Processor (TRIP),
  • FDDI Interface Processor (FIP),
  • High-Speed Serial Interface (HSSI) Interface Processor (HIP),
  • Fast Serial Interface Processor (FSIP),
  • Asynchronous Transfer Mode (ATM) Interface Processor (AIP),
  • MultiChannel Interface Processor (MIP),
  • Channel Interface Processor (CIP).

Маршрутизаторы Cisco 7000 обеспечивают общую скорость продвижения пакетов 270000 п/с.

Отличительные особенности серии Cisco 7000

  • Горячая программная переконфигурация системы (On-line software reconfiguration). Допускается изменять параметры системы без перезагрузки или остановки работы приложений и сервисов.
  • Горячая вставка и замена. Допускается горячая замена интерфейсных процессоров без перезагрузки или остановки работы приложений и сервисов. При этом не требуется вмешательства оператора, так как интерфейсные процессоры переконфигурируются автоматически .
  • Быстрая загрузка. Обеспечивается быстрая загрузка системы (обычно 35 секунд) после обновления (upgrade) программного обеспечения с минимальным влиянием на сеть.
  • Мониторинг сетевой среды. При неустойчивой работе системы выдается предупреждение оператору, что позволяет ему предпринять какие-либо меры до того, как произойдет сбой.
  • Самодиагностика. Перед тем, как начать работу с модулем, система проверяет его работоспособность, чтобы в дальнейшем избежать ошибок.
  • Поддержка двух источников питания. Допускается применение двух источников питания, каждый из которых имеет свой собственный сетевой шнур, чтобы уменьшить риск, связанный с возможными проблемами в электросети.
  • Перепрограммируемое ПЗУ (flash erasable programmable read-only memory - EPROM). Возможна быстрая, надежная и централизованная замена микрокода ПЗУ всех существующих в сети маршрутизаторов без необходимости присутствия оператора в физических местах их расположения.

Серия 7500 - это новая серия многопротокольных маршрутизаторов, объявленная в сентябре 1995 года и пришедшая на замену маршрутизаторов серии 7000, которые по данным IDC заняли 59% рынка магистральных маршрутизаторов.

Серия 7500 во многом похожа на серию 7000, но отличается от нее в нескольких отношениях:

  • Мультипроцессорная архитектура,
  • Шасси с большим количеством слотов,
  • Улучшенная отказоустойчивость,
  • Более быстрые внутренние шины.

Крайне важно, что обеспечена совместимость с модулями серии 7000 - все устанавливаемые в слоты модули модели 7000 могут быть установлены в шасси модели 7500. Основное отличие новых интерфейсных модулей заключается в том, что они снабжены RISC-процессорами , разгружающими центральные процессорные модули (рисунок 3.9).

Шасси старшей модели 7513 имеет 13 слотов, в 11 из которых могут устанавливаться интерфейсные модули. Для первой реализации модели 7513 предлагаются следующие интерфейсные модули:

  • 100Base-T - 2 порта,
  • Token Ring - 6 портов,
  • 10Base-T - 6 портов,
  • WAN-связи - 6 портов.

В отличие от одной внутренней шины серии 7000 с пропускной способностью только 500 Мб/с, шасси модели 7513 имеет 2 шины с пропускной способностью по 1 Гб/с каждая. К этим шинам подключаются два центральных модуля RPS (Rout Processor Switch), на которых ра ботает операционная система IOS. Вместо процессора с тактовой частотой 33 МГц моделей серии 7000 в модулях RSP использованы RISC-процессоры с тактовой частотой 100 МГц.

Компания Cisco планирует в ближайшее время снабдить маршрутизаторы серии 7500 функцией сервера маршрутизации для поддержания модели виртуального маршрутизатора в сетях, использующих коммутаторы. Для этого требуется внести соответствующие изменения в IOS, а также в коммутаторы Catalyst. Новая версия IOS также будет в состоянии загружать маршрутные таблицы в интерфейсные модули серии 7500, которые будут иметь возможность самостоятельно принимать маршрутные решения без участия центральных модулей RPS.

Рис. 3.9. Структура маршрутизаторов новой серии Cisco 7500

Предыдущая глава | Оглавление | Следующая глава

Back Home E-mail

Copyright © CIT


Управление неоднородными сетями

Мощные многофункциональные системы управления, такие как HP OpenView или Sun NetManager, существуют и совершенствуются уже много лет, однако для управления неоднородными сетями они пока оснащены явно недостаточно. Система OpenView компании Hewlett-Packard хорошо справляется с управлением сетями, построенными в основном на оборудовании компании Hewlett-Packard, система Spectrum компании Cabletron демонстрирует впечатляющие функциональные возможности при управлении сетями, построенными на оборудовании именн о этой компании и т.д.

Такое положение сложилось в силу нескольких причин:

  1. Наличие наряду со стандартными базами управляющей информации, типа MIB-I, MIB-II или RMON MIB, более тысячи фирменных баз MIB со своей структурой объектов, отражающей некоторые нестандартные особенности оборудования.
  2. Очень быстрый выпуск на рынок новых моделей и даже новых семейств моделей коммуникационного оборудования - разработчики систем управления не успевают включать в свои продукты новые базы MIB и новые описания (в том числе и графические) выпускаемого обо рудования.
  3. Существование нескольких протоколов управления: протокол SNMP широко используется в оборудовании локальных сетей, протокол CMIP более популярен среди разработчиков оборудования для территориальных сетей, а для управления серверами и рабочими станциями разработан протокол DMI со своим форматом управляющей информации MIF.

В результате при построении карты сети, которая состоит из оборудования разных производителей, системы управления начинают ошибаться и принимать одни устройства за другие, а при управлении этими устройствами поддерживают только их основные функции, а мног ие полезные дополнительные функции, которые отличают данное устройство от остальных, система управления просто не понимает и поэтому не может ими воспользоваться.

Для исправления этого недостатка разработчики систем управления включают поддержку не только стандартных баз MIB I, MIB II и RMON MIB, но и многочисленных частных MIB фирм-производителей. Лидер в этой области - система Spectrum, поддерживающая около 1000 баз MIB различных производителей.

Другим способом более качественной поддержки конкретной аппаратуры является использование на основе какой-либо платформы управления приложения той фирмы, которая выпускает это оборудование. Ведущие компании - производители коммуникационного оборудования - разработали и поставляют весьма сложные и многофункциональные системы управления для своего оборудования. К наиболее известным системам этого класса относятся Optivity компании Bay Networks, CiscoWorks компании Cisco Systems, Transcend компании 3Com. Сис тема Optivity, например, позволяет производить мониторинг и управлять сетями, состоящими из маршрутизаторов, коммутаторов и концентраторов компании Bay Networks, полностью используя все их возможности и свойства. Оборудование других производителей поддерж ивается на уровне базовых функций управления. Система Optivity работает на платформах OpenView компании Hewlett-Packard и SunNet Manager (предшественник Solstice) компании SunSoft. Однако, работа на основе какой-либо платформы управления с несколькими сис темами, такими как Optivity, слишком сложна и требует, чтобы компьютеры, на которых все это будет работать, обладали очень мощными процессорами и большой оперативной памятью.

Тем не менее, если в сети преобладает оборудование от какого-либо одного производителя, то наличие приложений управления этого производителя для какой-либо популярной платформы управления позволяет администраторам сети успешно решать многие задачи. Поэтом у разработчики платформ управления поставляют вместе с ними инструментальные средства, упрощающие разработку приложений, а наличие таких приложений и их количество считается очень важным фактором при выборе платформы управления.

Открытость платформы управления зависит также от формы хранения собранных данных о состоянии сети. Большинство платформ-лидеров позволяют хранить данные в коммерческих базах данных, таких как, например, Oracle, Ingres или Informix. Использование универсал ьных СУБД снижает скорость работы системы управления по сравнению с хранением данных в файлах операционной системы, но зато позволяет обрабатывать эти данные любыми приложениями, умеющими работать с этими СУБД.

В следующей таблице представлены наиболее важные характеристики наиболее популярных платформ управления:
OpenView
Network Node
Manager 4.1
(Hewlett-Packard)		Spectrum
Enterprise
Manager
(Cabletron Systems)		NetView for AIX
SNMP
Manager
(IBM)		Solstice
Enterprise
Manager
(SunSoft)
Автообнаружение
Ограничение по числу промежуточных маршрутизаторов--++
Определение имени хоста по его адресу через сервер DNS++++
Возможность модификации
присвоенного имени хоста		+- ++
Распознавание сетевых
топологий		Любые сети, работающие по TCP/IPEthernet, Token Ring, FDDI, ATM,
распределенные сети, сети с коммутацией		Ра спознавание по интерфейсам устройствEthernet, Token Ring, FDDI, распределен-
ные сети
Максимальное рекомендуемое число обслуживаемых узлов200 - 2000,
наибольшее
изв. - 35000		Программных ограничений не существуетПрограммных ограничений не существует10000 - 50000
Поддержка баз данных | Ingres, Oracle | файлы | Собств., Oracle, Sybase, ... | Informix, Oracle, Sybase
Распределенное управление
Один сервер/много клиентов
Число клиентов | до 15 | Нет программного ограничения | Протестировано более 30 | Нет программного огранич.
Клиент использует X-Window+- -+
Система с GUI запускается
на клиенте		++++
Собственная карта сети
у клиента		+++-
Задание доступных для
просмотра объектов сети		с помощью дополнительного продукта Operations Center (HP)++-
Много серверов/много клиентов
Текущее состояние+/-+/++/-+/+
Планируется+/++/++/++/+
Число приложений третьих фирм | 220 | 180 | > 200 | 400
Число поддерживаемых MIB третьих фирм218> 1000193Нет
данных
Поддержка протокола SNMP:
Через IP++++
Через IPX+---
Поддержка MIB,
утвержденных IETF 		Большинство, но нет RMONВсе20MIB-II
Поддержка протокола CMIPДополнительно оплачиваемый продукт - OpenView HP Distributed Management PlatformДополнительно оплачиваемый
продукт 		++
Взаимодействие с мэйнфреймамиПри помощи приложений третьих фирмПо SNA
через BlueVision		Может обращаться к NetView на мэйнфрейме+
Поддержка ОС | HP UX, Sun OS, Solaris | IBM AIX, Sun OS, HP UX, SGI IRIX, Windows NT | AIX, OSF/1, Windows NT | Solaris SPARC

Предыдущая глава | Оглавление | Следующая глава

Back Home E-mail

Copyright © CIT


Приложени

Center for Information Techno logies Сервер Информационных Технологий
содержит море(!) аналитической информации

Сервер поддерживается
Центром Информаци онных Технологий
(095) 932-9212, 932-9213, 939-0783
E-mail: info@citmgu.msk.su

Приложения

Протокол, интерфейс, стек протоколов. Модель ISO/OSI

Чтобы упростить проектирование, анализ и реализацию процедуры обмена сообщениями между пользователями или прикладными программами, работающими на разных компьютерах, эту процедуру декомпозируют на несколько иерархически связанных между собой частных задач , то есть используют многоуровневый подход.

При передаче сообщений оба участника сетевого обмена должны принять множество соглашений. Например, они должны согласовать уровни и форму электрических сигналов, способ определения длины сообщений, договориться о методах контроля достоверности и т.п. Друг ими словами, соглашения должны быть приняты для всех уровней, начиная от самого низкого уровня передачи битов, до самого высокого уровня, детализирующего, как информация должна быть интерпретирована. Такие формализованные правила, определяющие последовате льность и формат сообщений, которыми обмениваются сетевые компоненты, лежащие на одном уровне, но в разных узлах, называются протоколами.

Иерархически организованная совокупность протоколов, решающих задачу взаимодействия узлов сети называется стеком коммуникационных протоколов.

Протоколы соседних уровней, находящихся в одном узле, взаимодействуют друг с другом также в соответствии с четко определенными правилами и с помощью стандартизованных форматов сообщений. Эти правила принято называть интерфейсом. Интерфейс определяе т набор услуг, которые нижележащий уровень предоставляет вышележащему.

Международная Организация по Стандартам (International Standards Organization, ISO) разработала модель, которая четко определяет различные уровни взаимодействия систем, дает им стандартные имена и указывает, какую работу должен делать каждый уровень. Эта модель называется моделью взаимодействия открытых систем (Open System Interconnection, OSI) или моделью ISO/OSI.

В модели OSI взаимодействие делится на семь уровней или слоев, как показано на рисунке 5.1. Каждый уровень имеет дело с одним определенным аспектом взаимодействия. Таким образом, проблема взаимодействия декомпозирована на 7 частных проблем, каждая из кото рых может быть решена независимо от других. Каждый уровень поддерживает интерфейсы с выше- и нижележащими уровнями.

Модель OSI описывает только системные средства взаимодействия, не касаясь приложений конечных пользователей. Приложения реализуют свои собственные протоколы взаимодействия, обращаясь к системным средствам. Следует иметь ввиду, что приложение может взять н а себя функции некоторых верхних уровней модели OSI, в таком случае при необходимости обмена данными оно обращается напрямую к системным средствам, выполняющим функции оставшихся нижних уровней модели OSI.

Приложение конечного пользователя может использовать системные средства взаимодействия не только для организации диалога с другим приложением, выполняющимся на другой машине, но и просто для получения услуг того или иного сетевого сервиса, например, досту па к удаленным файлам, получение почты или печати на разделяемом принтере.

Рис. 5.1. Модель взаимодействия открытых систем ISO/OSI

Итак, пусть приложение обращается с запросом к прикладному уровню, например к файловому сервису. На основании этого запроса программное обеспечение прикладного уровня формирует сообщение стандартного формата, в которое помещает служебную информацию (загол овок) и, возможно, передаваемые данные. Затем это сообщение направляется представительному уровню. Представительный уровень добавляет к сообщению свой заголовок и передает результат вниз сеансовому уровню, который в свою очередь добавляет свой заголовок и т.д. Некоторые реализации протоколов предусматривают наличие в сообщении не только заголовка, но и концевика. Наконец, сообщение достигает самого низкого, физического уровня, который действительно передает его по линиям связи. К этому моменту сообщение в ыглядит так, как показано на рисунке 5.2. (Здесь мы сознательно упростили картину, не рассматривая пока процедуры сборки-разборки пакетов.)

Рис. 5.2. Вложенность пакетов различных уровней

Когда сообщение по сети поступает на другую машину, оно последовательно перемещается вверх с уровня на уровень. Каждый уровень анализирует, обрабатывает и удаляет заголовок своего уровня, выполняет соответствующие данному уровню функции и передает сообщен ие вышележащему уровню.

В модели OSI различается два основных типа протоколов. В протоколах с установлением соединения (connection-oriented network service, CONS) перед обменом данными отправитель и получатель должны сначала установить соединение и, возможно, выбрать прот окол, который они будут использовать. После завершения диалога они должны разорвать это соединение.

Вторая группа протоколов - протоколы без предварительного установления соединения (connectionless network service, CLNS). Такие протоколы называются также дейтаграммными протоколами. Отправитель просто передает сообщение, когда оно готово. П ри взаимодействии компьютеров используются как те, так и другие протоколы.

Функции уровней модели OSI

Модель ISO/OSI определяет функции уровней следующим образом:

Физический уровень. Этот уровень имеет дело с передачей битов по физическим каналам, таким, например, как коаксиальный кабель, витая пара или оптоволоконный кабель. К этому уровню имеют отношение характеристики физических сред передачи данных, таки е, как полоса пропускания, помехозащищенность, волновое сопротивление и другие. На этом же уровне определяются характеристики электрических сигналов, такие как требования к фронтам импульсов, уровням напряжения или тока передаваемого сигнала, тип кодирова ния, скорость передачи сигналов. Кроме этого, здесь стандартизуются типы разъемов и назначение каждого контакта.

Функции физического уровня реализуются во всех устройствах, подключенных к сети. Со стороны компьютера функции физического уровня выполняются сетевым адаптером. Повторители являются единственным типом оборудования, которое работает только на физическом ур овне.

Примером протокола физического уровня может служить спецификация 10Base-T технологии Ethernet, которая определяет в качестве используемого кабеля неэкранированную витую пару категории 3 с волновым сопротивлением 100 Ом, разъем RJ-45, максимальную длину фи зического сегмента 100 метров, манчестерский код для представления данных на кабеле, и другие характеристики среды и электрических сигналов.

Канальный уровень. На физическом уровне просто пересылаются биты. При этом не учитывается, что в некоторых сетях, в которых линии связи используются (разделяются) попеременно несколькими парами взаимодействующих компьютеров, физическая среда переда чи может быть занята. Поэтому одной из задач канального уровня является проверка доступности среды передачи. Другой задачей канального уровня является реализация механизмов обнаружения и коррекции ошибок. Для этого на канальном уровне биты группируются в наборы, называемые кадрами (frame). Канальный уровень обеспечивает корректность передачи каждого кадра, помещая специальную последовательность бит в начало и конец каждого кадра, чтобы отметить его, а также вычисляет контрольную сумму, суммируя все байты кадра определенным способом и добавляя контрольную сумму к кадру. Когда кадр приходит, получатель снова вычисляет контрольную сумму полученных данных и сравнивает результат с контрольной суммой из кадра. Если они совпадают, кадр считается правильны м и принимается. Если же контрольные суммы не совпадают, то фиксируется ошибка.

В локальных сетях протоколы канального уровня используются компьютерами, мостами, коммутаторами и маршрутизаторами. В компьютерах функции канального уровня реализуются совместными усилиями сетевых адаптеров и их драйверов.

Сетевой уровень. Протокол канального уровня обеспечивает доставку данных между любыми узлами только в сети с соответствующей типовой топологией. Это очень жесткое ограничение, которое не позволяет строить сети с развитой структурой, например , сети, объединяющие несколько сетей предприятия в единую сеть, или высоконадежные сети, в которых существуют избыточные связи между узлами. Для того, чтобы с одной стороны сохранить простоту процедур передачи данных для типовых топологий, а с другой стор оны допустить использование произвольных топологий, вводится дополнительный сетевой уровень. На этом уровне вводится более узкое понятие "сеть". В данном случае под сетью понимается совокупность компьютеров, соединенных между собой в соот ветствии с одной из стандартных типовых топологий и использующих для передачи данных один из протоколов канального уровня, определенный для этой топологии.

Таким образом, внутри сети доставка данных регулируется канальным уровнем, а вот доставкой данных между сетями занимается сетевой уровень. Сообщения сетевого уровня принято называть "пакетами" (packet). При организации доставки пакетов на сетево м уровне используется понятие "номер сети". В этом случае адрес получателя состоит из номера сети и номера компьютера в этой сети.

Сети соединяются между собой специальными устройствами, называемыми маршрутизаторами. Маршрутизатор - это устройство, которое собирает информацию о топологии межсетевых соединений и на ее основании пересылает пакеты сетевого уровня в сеть назначени я. Для того, чтобы передать сообщение от отправителя, находящегося в одной сети, получателю, находящемуся в другой сети, нужно совершить некоторое количество транзитных передач (hops) между сетями, каждый раз выбирая подходящий маршрут. Таким образом, мар шрут представляет собой последовательность маршрутизаторов, через которые проходит пакет.

Проблема выбора наилучшего пути называется маршрутизацией, и ее решение является главной задачей сетевого уровня. Эта проблема осложняется тем, что самый короткий путь не всегда самый лучший. Часто критерием при выборе маршрута является время перед ачи данных по этому маршруту; оно зависит от пропускной способности каналов связи и интенсивности трафика, которая может изменяться с течением времени. Некоторые алгоритмы маршрутизации пытаются приспособиться к изменению нагрузки, в то время, как другие принимают решения на основе средних показателей за длительное время. Выбор маршрута может осуществляться и по другим критериям, например, надежности передачи.

На сетевом уровне определяется два вида протоколов. Первый вид относится к определению правил передачи пакетов с данными конечных узлов от узла к маршрутизатору и между маршрутизаторами. Именно эти протоколы обычно имеют в виду, когда говорят о протоколах сетевого уровня. Однако часто к сетевому уровню относят и другой вид протоколов, называемых протоколами обмена маршрутной информацией. С помощью этих протоколов маршрутизаторы собирают информацию о топологии межсетевых соединений.

Протоколы сетевого уровня реализуются программными модулями операционной системы, а также программными и аппаратными средствами маршрутизаторов.

Примерами протоколов сетевого уровня являются протокол межсетевого взаимодействия IP стека TCP/IP и протокол межсетевого обмена пакетами IPX стека Novell.

Транспортный уровень. На пути от отправителя к получателю пакеты могут быть искажены или утеряны. Хотя некоторые приложения имеют собственные средства обработки ошибок, существуют и такие, которые предпочитают сразу иметь дело с надежным соединение м. Работа транспортного уровня заключается в том, чтобы обеспечить приложениям или верхним уровням стека - прикладному и сеансовому - передачу данных с той степенью надежности, которая им требуется. Модель OSI определяет пять классов сервиса, предоставляе мых транспортным уровнем. Эти виды сервиса отличаются качеством предоставляемых услуг: срочностью, возможностью восстановления прерванной связи, наличием средств мультиплексирования нескольких соединений между различными прикладными протоколами через общи й транспортный протокол, а главное - способностью к обнаружению и исправлению ошибок передачи, таких как искажение, потеря и дублирование пакетов.

Выбор класса сервиса транспортного уровня определяется с одной стороны тем, в какой степени задача обеспечения надежности решается самими приложениями и протоколами более высоких, чем транспортный, уровней, а с другой стороны, этот выбор зависит от того, насколько надежной является вся система транспортировки данных в сети. Так, например, если качество каналов передачи связи очень высокое, и вероятность возникновения ошибок, не обнаруженных протоколами более низких уровней, невелика, то разумно воспользов аться одним из облегченных сервисов транспортного уровня, не обремененных многочисленными проверками, квитированием и другими приемами повышения надежности. Если же транспортные средства изначально очень ненадежны, то целесообразно обратиться к наиболее р азвитому сервису транспортного уровня, который работает, используя максимум средств для обнаружения и устранения ошибок - с помощью предварительного установления логического соединения, контроля доставки сообщений с помощью контрольных сумм и циклической нумерации пакетов, установления тайм-аутов доставки и т.п.

Начиная с транспортного уровня, все вышележащие протоколы реализуются программными средствами, обычно включаемыми в состав сетевой операционной системы. В качестве примера транспортных протоколов можно привести протоколы TCP и UDP стека TCP/IP и протокол SPX стека Novell.

Сеансовый уровень. Сеансовый уровень обеспечивает управление диалогом для того, чтобы фиксировать, какая из сторон является активной в настоящий момент, а также предоставляет средства синхронизации. Последние позволяют вставлять контрольные точки в длинные передачи, чтобы в случае отказа можно было вернуться назад к последней контрольной точке, вместо того, чтобы начинать все с начала. На практике немногие приложения используют сеансовый уровень, и он редко реализуется.

Уровень представления. Этот уровень обеспечивает гарантию того, что информация, передаваемая прикладным уровнем, будет понятна прикладному уровню в другой системе. В случаях необходимости уровень представления выполняет преобразование форматов данн ых в некоторый общий формат представления, а на приеме, соответственно, выполняет обратное преобразование. Таким образом прикладные уровни могут преодолеть, например, синтаксические различия в представлении данных. На этом уровне может выполняться шифрова ние и дешифрование данных, благодаря которому секретность обмена данными обеспечивается сразу для всех прикладных сервисов. Примером такого протокола является протокол Secure Socket Layer (SSL), который обеспечивает секретный обмен сообщениями дл протоколов прикладного уровня стека TCP/IP.

Прикладной уровень. Прикладной уровень - это в действительности просто набор разнообразных протоколов, с помощью которых пользователи сети получают доступ к разделяемым ресурсам, таким как файлы, принтеры или гипертекстовые Web-страницы, а также ор ганизуют свою совместную работу, например с помощью протокола электронной почты. Единица данных, которой оперирует прикладной уровень, обычно называется сообщением (message).

Существует очень большое разнообразие сервисов прикладного уровня. Приведем в качестве примеров протоколов прикладного уровня хотя бы несколько наиболее распространенных реализаций файловых сервисов: NCP в операционной системе Novell NetWare, SMB в Micros oft Windows NT, NFS, FTP и TFTP, входящие в стек TCP/IP.

Сетезависимые протоколы и протоколы, ориентированные на приложени

Функции всех уровней модели OSI могут быть отнесены к одной из двух групп: либо к функциям, зависящим от конкретной технической реализации сети, либо к функциям, ориентированным на работу с приложениями.

Три нижних уровня - физический, канальный и сетевой - являются сетезависимыми, то есть протоколы этих уровней тесно связаны с технической реализацией сети, с используемым коммуникационным оборудованием. Например, переход на оборудование FDDI означает полн ую смену протоколов физического и канального уровня во всех узлах сети.

Три верхних уровня - сеансовый, уровень представления и прикладной - ориентированы на приложения и мало зависят от технических особенностей построения сети. На протоколы этих уровней не влияют никакие изменения в топологии сети, замена оборудования или пе реход на другую сетевую технологию. Так, переход от Ethernet на высокоскоростную технологию 100VG-AnyLAN не потребует никаких изменений в программных средствах, реализующих функции прикладного, представительного и сеансового уровней.

Транспортный уровень является промежуточным, он скрывает все детали функционирования нижних уровней от верхних уровней. Это позволяет разрабатывать приложения, независящие от технических средств, непосредственно занимающихся транспортировкой сообщений.

Компьютер с установленной на нем сетевой ОС взаимодействует с другим компьютером с помощью протоколов всех семи уровней. Это взаимодействие компьютеры осуществляют опосредовано через различные коммуникационные устройства: концентраторы, модемы, мосты, ком мутаторы, маршрутизаторы, мультиплексоры. В зависимости от типа, коммуникационное устройство может работать либо только на физическом уровне (повторитель), либо на физическом и канальном (мост), либо на физическом, канальном и сетевом, иногда захватывая и транспортный уровень (маршрутизатор).

Модель OSI представляет хотя и очень важную, но только одну из многих моделей коммуникаций. Эти модели и связанные с ними стеки протоколов могут отличаться количеством уровней, их функциями, форматами сообщений, сервисами, предоставляемыми на верхних уров нях и прочими параметрами.

Стандартные стеки коммуникационных протоколов

Существует достаточно много стеков протоколов, широко применяемых в сетях. Это и стеки, являющиеся международными и национальными стандартами, и фирменные стеки, получившие распространение благодаря распространенности оборудования той или иной фирмы. Прим ерами популярных стеков протоколов могут служить: стек IPX/SPX фирмы Novell, стек TCP/IP, используемый в сети Internet и во многих сетях на основе операционной системы UNIX, стек OSI международной организации по стандартизации, стек DECnet корпорации Digi tal Equipment и некоторые другие.

Использование в сети того или иного стека коммуникационных протоколов во многом определяет лицо сети и ее характеристики. В небольших сетях может использоваться исключительно один стек. В крупных корпоративных сетях, объединяющих различные сети, параллель но используются, как правило, несколько стеков.

В коммуникационном оборудовании реализуются протоколы нижних уровней, которые в большей степени стандартизованы, чем протоколы верхних уровней, и это является предпосылкой для успешной совместной работы оборудования различных производителей. Перечень прот околов, поддерживаемых тем или иным коммуникационным устройством, является одной из наиболее важных характеристик этого устройства.

Компьютеры реализуют коммуникационные протоколы в виде соответствующих программных элементов сетевой операционной системы, например, протоколы канального уровня, как правило, выполнены в виде драйверов сетевых адаптеров, а протоколы верхних уровней в виде серверных и клиентских компонент сетевых сервисов.

Умение хорошо работать в среде той или иной операционной системы является важной характеристикой коммуникационного оборудования. Часто можно прочитать в рекламе сетевого адаптера или концентратора, что он разрабатывался специально для работы в сети NetWar e или UNIX. Это означает, что разработчики аппаратуры оптимизировали ее характеристики применительно к тем протоколам, которые используются в этой сетевой операционной системе, или к данной версии их реализации, если эти протоколы используются в различных ОС. Из-за особенностей реализации протоколов в различных ОС в качестве одной из характеристик коммуникационного оборудования используется его сертифицированность на возможность работы в среде данной ОС.

На нижних уровнях - физическом и канальном - практически во всех стеках используются одни и те же протоколы. Это хорошо стандартизованные протоколы Ethernet, Token Ring, FDDI и некоторые другие, которые позволяют использовать во всех сетях одну и ту же ап паратуру.

Протоколы сетевого и более высоких уровней существующих стандартных стеков отличаются большим разнообразием и, как правило, не соответствуют рекомендуемому моделью ISO разбиению на уровни. В частности, в этих стеках функции сеансового и представительного уровня чаще всего объединены с прикладным уровнем. Такое несоответствие связано с тем, что модель ISO появилась как результат обобщения уже существующих и реально используемых стеков, а не наоборот.

Стек OSI. Следует четко различать модель OSI и стек OSI. В то время как модель OSI является концептуальной схемой взаимодействия открытых систем, стек OSI представляет собой набор вполне конкретных спецификаций протоколов. В отличие от других стеко в протоколов стек OSI полностью соответствует модели OSI, он включает спецификации протоколов для всех семи уровней взаимодействия, определенных в этой модели. На нижних уровнях OSI поддерживает Ethernet, Token Ring, FDDI, а также такие протоколы как LLC, X.25 и ISDN. Сервисы сетевого, транспортного и сеансового уровней этого стека пока мало распространены. Наиболее популярными протоколами стека OSI являются протоколы, реализующие высокоуровневые сервисы по передаче файлов, эмуляции терминала, ведению кат алогов имен и по организации электронной почты. Хотя в стеке OSI предусматривается еще ряд дополнительных высокоуровневых сервисов, многие из них еще не реализованы или реализованы частично.

Из-за своей сложности протоколы OSI требуют больших затрат вычислительной мощности центрального процессора, что делает их более подходящими для мощных машин, а не для сетей персональных компьютеров.

Стек OSI - международный, независимый от производителей, стандарт. Его поддерживает правительство США в своей программе GOSIP, в соответствии с которой все компьютерные сети, устанавливаемые в правительственных учреждениях США после 1990 года, должны или непосредственно поддерживать стек OSI, или обеспечивать средства для перехода на этот стек в будущем. Тем не менее, стек OSI более популярен в Европе, а не в США, так как в Европе меньше установлено старых сетей, использующих свои собственные протоколы. Б ольшинство организаций пока только планируют переход к стеку OSI, и очень немногие приступили к созданию пилотных проектов. Из тех, кто работает в этом направлении, можно назвать Военно-морское ведомство США и сеть NFSNET. Одним из крупнейших производител ей, поддерживающих OSI, является компания AT&T, ее сеть Stargroup полностью базируется на этом стеке.

Стек TCP/IP. Стек был разработан по инициативе Министерства обороны США (Department of Defense, DoD) более 20 лет назад для связи экспериментальной сети
ARPAnet с другими сетями как набор общих протоколов для разнородной вычислительной среды. Большой вклад в развитие стека TCP/IP, который получил свое название по популярным транспортным протоколам IP и TCP, внес университет Беркли, реализовав протоколы ст ека в своей версии ОС UNIX. Популярность этой операционной системы привела к широкому распространению протоколов TCP, IP и других протоколов стека. Этот стек используется для связи компьютеров всемирной информационной сети Internet. Организация Internet E ngineering Task Force (IETF) вносит основной вклад в совершенствование стандартов стека, публикуемых в форме спецификаций RFC.

Стек TCP/IP на нижнем уровне поддерживает все популярные стандарты физического и канального уровня: для локальных сетей это Ethernet, Token Ring, FDDI, для глобальных - протоколы работы на аналоговых коммутируемых и выделенных линиях SLIP/PPP, протоколы т ерриториальных сетей X.25 и ISDN.

В качестве основного протокола сетевого уровня в стеке используется протокол Internet Protocol (IP), который изначально проектировался как протокол передачи пакетов в сетях, состоящих из большого количества локальных сетей, объединенных как локальными, та к и глобальными связями. Поэтому стек TCP/IP хорошо работает в сетях со сложной топологией, рационально используя наличие в них подсистем и экономно расходуя пропускную способность низкоскоростных линий связи.

За долгие годы использования в сетях различных стран и организаций стек TCP/IP вобрал в себя большое количество протоколов прикладного уровня. К ним относятся такие популярные протоколы как протокол пересылки файлов FTP, протокол эмуляции терминала telnet , почтовый протокол SMTP, используемый в электронной почте сети Internet, гипертекстовые сервисы доступа к удаленной информации, такие как Mosaic, и многие другие.

Все говорит о том, что стек TCP/IP станет наиболее распространенным в ближайшем будущем. Если в настоящее время он распространен в основном в UNIX-сетях, то реализация его в последних версиях сетевых операционных систем для персональных компьютеров (Windo ws 95, Windows NT, NetWare 4.1) приведет к еще большему его распространению. По данным IDC в 1994 году стек TCP/IP использовался в 9.5% настольных систем, 2.5% серверов локальных сетей, 35.1% систем средних среднего класса и в 17.3% сетей на основе мейнфр еймов. По прогнозам IDC в 1998 году эти цифры существенно изменяться и будут равны 50.3%, 18.2%, 59% и 40.8% соответственно.

Стек IPX/SPX. Этот стек является оригинальным стеком протоколов фирмы Novell, разработанным для сетевой операционной системы NetWare еще в начале 80-х годов. Протоколы сетевого и сеансового уровня Internetwork Packet Exchange (IPX) и Sequ enced Packet Exchange (SPX), которые дали название стеку, являются прямой адаптацией протоколов XNS фирмы Xerox, распространенных в гораздо меньшей степени, чем стек IPX/SPX. Популярность стека IPX/SPX непосредственно связана с операционной системой N ovell NetWare, которая, несмотря на то, что ее популярность несколько снизилась в последнее время, все еще сохраняет мировое лидерство по числу установок .

Многие особенности стека IPX/SPX обусловлены ориентацией ранних версий ОС NetWare (до версии 4.0) на работу в локальных сетях небольших размеров, состоящих из персональных компьютеров со скромными ресурсами. Понятно, что для таких компьютеров Novell нужны были протоколы, на реализацию которых требовалось бы минимальное количество оперативной памяти (ограниченной в IBM-совместимых компьютерах под управлением MS-DOS 640 Кбайтами) и которые бы быстро работали на процессорах небольшой вычислительной мощности. В результате протоколы стека IPX/SPX до недавнего времени хорошо работали в локальных сетях и не очень - в больших корпоративных сетях, так как они слишком перегружали медленные глобальные связи широковещательными пакетами, которые интенсивно используютс я несколькими протоколами этого стека (например, для установления связи между клиентами и серверами). Это обстоятельство, а также тот факт, что стек IPX/SPX является собственностью фирмы Novell, и на его реализацию нужно получать у нее лицензию, долгое вр емя ограничивали распространенность его только сетями NetWare. Однако с момента выпуска версии NetWare 4.0 Novell внесла и продолжает вносить в свои протоколы серьезные изменения, направленные на приспособление их для работы в корпоративных сетях. Сейчас стек IPX/SPX реализован не только в NetWare, но и в нескольких других популярных сетевых ОС, например, SCO UNIX, Sun Solaris, Microsoft Windows NT.

Стек NetBIOS/SMB. Этот стек широко используется в продуктах компаний IBM и Microsoft. На физическом и канальном уровнях этого стека используются все наиболее распространенные протоколы Ethernet, Token Ring, FDDI и другие. На верхних уровнях работаю т протоколы NetBEUI и SMB.

Протокол NetBIOS (Network Basic Input/Output System) появился в 1984 году как сетевое расширение стандартных функций базовой системы ввода/вывода (BIOS) IBM PC для сетевой программы PC Network фирмы IBM. В дальнейшем этот протокол был заменен так н азываемым протоколом расширенного пользовательского интерфейса NetBEUI - NetBIOS Extended User Interface. Для обеспечения совместимости приложений в качестве интерфейса к протоколу NetBEUI был сохранен интерфейс NetBIOS. Протокол NetBEUI разрабатывался ка к эффективный протокол, потребляющий немного ресурсов, для использования в сетях, насчитывающих не более 200 рабочих станций. Этот протокол содержит много полезных сетевых функций, которые можно отнести к сетевому, транспортному и сеансовому уровням модел и OSI, однако с его помощью невозможна маршрутизация пакетов. Это ограничивает применение протокола NetBEUI локальными сетями, не разделенными на подсети, и делает невозможным его использование в составных сетях. Некоторые ограничения NetBEUI снимаются ре ализацией этого протокола NBF (NetBEUI Frame), которая включена в операционную систему Microsoft Windows NT.

Протокол блоков сообщений сервера SMB (Server Message Block) выполняет функции сеансового, представительного и прикладного уровней. SMB реализует файловый сервис, сервис печати и сервис передачи сообщений между приложениями.

Предыдущая глава | Оглавление

Back Home E-mail

Copyright © CIT


Created using
htm2chm 3.0

Download it NOW!


Транспортная подсистема неоднородных сетей

  1. Подходы к интеграции неоднородных сетей
    • Источники и типы неоднородностей в транспортной подсистеме
      • Использование различных базовых сетевых технологий
      • Использование нескольких протоколов сетевого уровня (IP, IPX, X.25)
      • Комбинирование разных протоколов сбора маршрутной информации (RIP, OSPF, NLSP)
      • Несовместимость оборудования разных производителей
    • Стратегии межсетевого взаимодействия
      • Трансляция протоколов
      • Мультиплексирование протоколов
      • Сравнение трансляции и мультиплексирования
      • Инкапсуляция (туннелирование) протоколов
  2. Средства согласования протоколов на физическом и канальном уровнях
    • Функции физического уровня. Средства согласования
    • Функции канального уровня модели OSI
    • Согласование типа и размера кадров в составных сетях
    • Согласование протоколов канального уровня мостами и коммутаторами
      • Инкапсулирующие мосты и коммутаторы
      • Транслирующие мосты и коммутаторы
    • Использование единого сетевого протокола в маршрутизаторах
    • Технология LAN Emulation для согласования сетей ATM и традиционных сетевых технологий
      • Назначение и общие принципы работы
      • Объединение локальных сетей через транзитную АТМ-сеть
      • Организация нескольких эмулируемых сетей
      • Организация взаимодействия всех узлов составной сети
      • Недостатки версии LAN Emulation 1.0 и пути ее совершенствования
    • Инкапсулирующая технология Data Link Switching (DLSw)
      • Назначение и история создания технологии
      • Принципы работы протокола DLSw
    • Примеры оборудования с функциями согласования протоколов канального уровня
      • Коммутатор Catalyst 5000 компании Cisco Systems
      • Коммутаторы CELLplex компании 3Com
  3. Средства согласования сетей на сетевом уровне
    • Шлюзы как средство трансляции сетевых протоколов
    • Поддержка нескольких независимых сетей с помощью многопротокольных маршрутизаторов
    • Мультиплексирование протоколов в конечных узлах
    • Инкапсуляция на сетевом уровне: X.25 поверх TCP, IPX поверх IP
    • Примеры многопротокольных и инкапсулирующих маршрутизаторов
      • Мост/маршрутизатор NETBuilder II компании 3Com
      • Семейство маршрутизаторов компании Bay Networks/Wellfleet
      • Маршрутизаторы компании Cisco
  4. Управление неоднородными сетями
  5. Приложения
    • Протокол, интерфейс, стек протоколов. Модель ISO/OSI
    • Стандартные стеки коммуникационных протоколов

Back Home E-mail

Copyright © CIT


Teleport Pro Messages

http://www.cit-forum.com/: This file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address.
http://www.ru/cit: This file was not retrieved by Teleport Pro, because it is addressed on a domain or path outside the boundaries set for its Starting Address.
http://www.hostel.cctpu.edu.ru/doc/Transport/contents.htm: This file was not retrieved by Teleport Pro, because the server reports that this file cannot be found.