Программные продукты и системы

В настоящее время в развитых странах идет процесс объединения уже существующих систем и сетей различных производителей в сквозные мультисетевые структуры, обеспечивающие (в числе других функций) непрерывность технологического цикла проектирования и производства продукции. Кроме того, вновь разрабатываемые для целей проектирования и производства сетевые структуры должны поддерживать различные по своей функциональности сети, что тоже налагает требования интеграции разнородных сетей. Например, к различным среднескоростным сетям подключаются рабочие станции САПР, оснащенные достаточно мощными вычислительными ресурсами, и автоматизированные рабочие места (АРМ) на базе ПЭВМ [1]. Среднескоростные сети в свою очередь могут подключаться к высокоскоростным сетям, обеспечивающим доступ к общим для предприятия ресурсам (файловым серверам и пр.)- Обеспечить не только совместимость таких систем и сетей, но и соответствие требованиям прикладной области призван, в частности, функциональный профиль TOP (Technical and Office Protocol) протоколов сетевой архитектуры взаимосвязи открытых систем OSI/ISO. Необходимость интеграции процессов проектирования, технологической подготовки производства и изготовления промышленной (а первую очередь — машиностроительной) продукции привела к объединению проектов ТОР — интеграция станций САПР конструкторов и технологов - и MAP (Manufacturing Automation Protocol) - интеграция автоматизированного технологического оборудования — в общий проект MAP/TOP.

. Отдельные сети объединяются в мультисетевые структуры (интерсети) с помощью средств межсетевой связи, которые также должны поддерживать выбранный профиль протоколов." Средства межсетевой связи в настоящее время представляют собой программируемые технические устройства, содержащие достаточно мощные процессоры (например класса "Motorola 680X0"). Программное обеспечение межсетевых устройств обычно поставляется как лицензионное: производится индивидуальная поставка (с индивидуальной копией программного обеспечения) каждого изделия под определенный профиль и класс протоколов. Таким образом, при желании разработать или купить межсетевое устройство необходимо знать ответ на следующие вопросы:

-     какие сети это устройство должно объ единять;

-     какие функции оно должно выполнять;

-     какие протоколы и какие классы протоколов поддерживать.

Профиль протоколов призван дать ответ на последний вопрос.

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

В качестве устройств межсетевой связи могут использоваться:

-     повторитель (repeater), предназначенный для объединения локальных сетей на физическом уровне модели сетевой архитектуры OSI/ISO (собственно для "расширения" сети, а не со здания интерсети);

-     мост (bridge), в функции которого входит объединение локальных сетей связи на каналь ном уровне модели сетевой архитектуры OSI/ISO (т.е. объединение физически изолиро ванных сетей в одну сеть);

-     маршрутизатор (router), необходимый для объединения локальных сетей на сетевом уров не модели сетевой архитектуры OSI/1SO (т.е. для создания логически различных сетей внут ри интерсети, путем формирования независи мых административных областей, использую щих единый протокол сетевого уровня);

-     шлюз (gateway), предназначенный для объ единения сетей на прикладном уровне модели сетевой архитектуры OS1/1SO (т.е. для объеди нения сетей, использующих совершенно разные стеки протоколов).

Рассмотрим более подробно мосты и маршрутизаторы (профиль ТОР пока не содержит спецификацию шлюзов, а повторители реализуются обычно без использования процессоров). Функции физического уровня и подуровня управления доступом к разделяемой среде связи канального уровня модели сетевой архитектуры OSI/ISO в рассматриваемых устройствах реализуются аппаратно. Поэтому ниже в статье будут рассматриваться только реализуемые чаще всего программно функции подуровня управления логическим каналом (Logical Link Control (LLC) sublayer) канального уровня и функции сетевого уровня межсетевых устройств. Необходимо отметить, что функции LLC-подуровня, реализуемые мостом, и функции сетевого уровня, реализуемые маршрутизатором, отличаются от функций аналогичных уровней, реализуемых в оконечных системах в связи с тем, что на межсетевые устройства возлагаются дополнительные функции фильтрации и маршрутизации.

Профиль протоколов

Спецификацией профиля ТОР [2] определяется, что ЛВС должны поддерживать протокол LLC-подуровня, соответствующий стандарту ISO 8802.2, а промежуточные системы (intermediate system), т.е. маршрутизаторы, осуществляющие объединение ЛВС, должны поддерживать протокол сетевого уровня без установления соединения (Connectionless-mode Network Protocol, или CLNP), соответствующий стандарту ISO 8473.

Стандарт ISO 8802.2 определяет четыре класса протоколов LLC-подуровня, из которых в профиле ТОР использовался только класс 1. В настоящее время в связи с включением в интерсети профиля ТОР высокоскоростных сетей, Международной федерацией производственных ЛВС типа MAP/TOP рассматривается расширение профиля ТОР, в котором на LLC-подуровне используются протоколы класса 1, класса 2 и класса 3.

Протокол LLC-подуровкя класса 1 поддерживает операции передачи данных в режиме без установления соединения (connectionless mode) (операции типа 1). Протокол LLC-подуровня класса 2 поддерживает операции типа 1 и операции типа 2 (т.е. операции передачи данных в режиме с установлением соединения (connection mode)). Протокол LLC-подуровня класса 3 поддерживает операции передачи данных в режиме без установления соединения (операции типа 1) и операции передачи данных в режиме без установления соединения с подтверждением (acknowledgement) (операции типа 3). Протокол класса 4 поддерживает операции передачи данных всех трех типов.

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

Операции типа 1 не обеспечивают никакого управления потоком.

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

Программное обеспечение LLC-мостов (т.е. мостов, объединяющих ЛВС на LLC-подуровне (в отличие от МАС-мостов)) должно включать в себя логический объект LLC-подуровня канального уровня (стандарт ISO 8802.2). Класс протокола LLC-подуровня, реализуемый в мосте, желательно должен быть таким, чтобы обеспечивать любой тип операций, поддерживаемых оконечными системами всех объединяемых подсетей.

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

-    логический объект протокола CLNP, обеспе чивающего взаимодействие объединяемых под сетей (стандарт ISO 8473);

-    логический объект протокола ES-IS (end system - intermediate system), обеспечивающего обмен маршрутной информацией между око нечными и промежуточными системами (стан дарт ISO 9542);

-    логический объект LLC-подуровня канально го уровня для каждого логического канала (стандарт ISO S802.2).

Кроме того, спецификацией профиля ТОР определяется, что маршрутизация между подсетями (фактически между маршрутизаторами) должна поддерживаться путем обновления информационной базы маршрутизации (Network Layer Routing Information Base) вручную (manual methods), - это включает использование удаленного сетевого менеджмента.

Алгоритмы выбора маршрута ретрансляторами

Устройства межсетевой связи осуществляют маршрутизацию на основе сетевых адресов (маршрутизаторы) и МАС-адресов (мосты). Алгоритмы выбора маршрута и обеспечения передачи данных между сетями будут предметом обсуждения в данном разделе.

Алгоритмы фильтрации в мостах

Фильтрация в мостах осуществляется на основе МАС-адресов отправителя и получателя, которые анализируются, и в зависимости от условий кадр пропускается или не пропускается прозрачно в другой сегмент интерсети. Простейший алгоритм фильтрации таков: мост получает из каждой сети, присоединенной к нему, все кадры и сравнивает в них МАС-адреса отправителя и получателя; если отправитель и получатель принадлежат одной сети, кадр сбрасывается, если — разным, то кадр отправляется в другую сеть (другие сети) [3,4]. Алгоритмы выбора сети, в которую необходимо отправить полученный кадр могут быть различными, но принципы выбора следующие:

-   кадр отправляется во все сети,кроме той, от куда пришел [3];

-   каким-либо образом (по МАС-адресу) опре деляется, в какую сеть необходимо отправить кадр, и кадр отправляется именно туда.

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

-   для каждой сети выделяется "окно" адресов (например, адреса 0-10 принадлежат станциям сети А, а адреса 11-20 принадлежат станциям сети В); при получении кадра сеть, в которую необходимо его отправить, определяется по принадлежности адреса получателя к одному из окон [5];

-   используется база данных моста (так назы ваемые "обучающиеся" (learning) мосты); при получении кадра из какой-либо сети адрес от правителя записывается в таблицу адресов, принадлежащих данной сети; адрес получателя ищется в подобных таблицах; если он найден - кадр отправляется в сеть, к которой относится данная таблица, если не найден - кадр отправ ляется во все сети кроме той, откуда пришел; :о временем адреса всех станций, осуществ ляющих обмен через мост, будут присутство вать в базе данных моста [3]; базы данных мо гут задаваться вручную [6];

-   используется алгоритм "покрывающего дере ва" (Spanning-Тгее Algorithm (STA)), при кото ром создается единственный путь между лю- эыми двумя сетями; совокупность всех путей доставляет дерево, "покрывающее" интерсеть; !то предотвращает "зацикливания" кадров и распространение "широковещательных штор мов" ("broadcast storms") [3,7];

-   используется "маршрутизация от источника" 'source routing) [5].

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

Маршрутизация на сетевом уровне

Общие принципы маршрутизации. Для осу-цествления маршрутизации необходимо иметь федставление о структуре используемой сети. Структура сети представляется взвешенным рафом, узлы которого являются оконечными 1ли промежуточными открытыми системами, а >ебра - линиями связи, соединяющими данные :истемы. Вес, присваиваемый ребрам графа, шж$т иметь тот или иной смысл, например ранзитная задержка блоков данных на соответ-твующем отрезке пути, стоимость прохожде-:ия данного участка, точность передачи данных вероятность необнаруженной ошибки) и т.п. 'аким образом, задача выбора маршрута в сети водится к задаче выбора кратчайшего пути в графе с той или иной метрикой. Работа алгоритмов выбора кратчайшего пути может быть эффективной только при ограниченном количестве вершин графа, поэтому задача выбора кратчайшего пути выполняется на графе, вершинами которого являются только узлы коммутации магистральной сети. Магистральной сетью назовем совокупность маршрутизаторов (узлов коммутации магистральной сети), осуществляющих связь между отдельными подсетями, и линий связи, соединяющих эти маршрутизаторы.

Существующие алгоритмы маршрутизации можно классифицировать следующим образом [8]:

-    централизованные (т.е. управление маршру тизацией осуществляется из центра управления сетью);

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

С другой стороны, алгоритмы маршрутизации делятся на:

-    статические (информация о структуре и ха рактеристиках сети на каждом узле коммута ции постоянна);

-    квазистатические (информация о структуре и характеристиках сети на каждом узле коммута ции меняется, но очень медленно);

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

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

-    получение информации о структуре и харак теристиках сети;

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

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

Реализация этого требования хорошо видна на примерах протоколов, используемых в сетях различных архитектур. Так, в интерсетях, использующих архитектуру TCP/IP, выбор маршрута осуществляется протоколом IP {Internet Protocol (для сетей типа IEEE 802 - документ RFC 1042 [9])), а сбор информации о структуре и характеристиках сети осуществляется протоколами RIP (Routing Information Protokol -документ RFC 1058 [10]) и OSPF (Open Shortest Path First - документ RFC 1131 [11]) [12,13]. В рамках сетевой архитектуры OSI логический объект, выполняющий выбор маршрута, должен поддерживать либо протокол CONP (Connection Oriented Network Protocol), либо протокол CLNP (Connectionless-mode Network Protocol - стандарт ISO 8473), а логические объекты, осуществляющие сбор информации о структуре и характеристиках сети, поддерживают протокол ES-IS (End System - Intermediate System - стандарт ISO 9542) и протокол 1S-IS (Intermediate System - Intermediate System). Рассматриваемый в профиле MAP/TOP объект, осуществляющий маршрутизацию, должен функционировать в соответствии с протоколом CLNP (стандарт ISO 8473), объект, получающий информацию о структуре и характеристиках локальных сетей, с которыми связан данный маршрутизатор, должен функционировать в соответствии с протоколом ES-IS (стандарт ISO 9542), а объект, получающий информацию о структуре и характеристиках интерсети, профилем ТОР не определяется, и этот вопрос необходимо рассмотреть отдельно.

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

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

В связи с применением новых компьютерных и коммуникационных технологий, новых стратегий взаимодействия, с увеличением загрузки сетей и их размеров, перед разработчиками интерсетей встают следующие вопросы [14]:

-    как обеспечить работу алгоритмов маршру тизации в условиях непрерывного роста интер сетей;

-    как создать алгоритм автоматического управ ления трафиком во всей интерсети;

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

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

В настящее время в мире существуют различные сетевые архитектуры (OSI, DDN (Defense Data Network, более известная как TCP/IP), SNA (Systems Network Architecture -сетевая архитектура фирмы IBM), DNA (DEC Network Architecture — сетевая архитектура фирмы DEC) и Др.), поддерживающие' различные протоколы.

Причем на практике более всего распространена сетевая архитектура TCP/IP. Некоторые исследователи [15] склоняются к тому, что протоколы архитектуры OS1 лучше разработаны для верхних уровней, а на сетевом уровне по-прежнему лидируют протоколы TCP/IP. Рассмотрим эти протоколы, поддерживаемые большинством маршрутизаторов различных производителей (маршрутизатор может одновременно поддерживать различные сетевые протоколы).

Протокол RIP [12,13] - наиболее распространенный межсетевой маршрутизирующий (routing) протокол, используемый практически всеми производителями маршрутизаторов дополнительно к саоим фирменным протоколам. Появился для использования с протоколами XNS (Xerox Network Systems), в дальнейшем был модифицирован для протоколов TCP/IP, распространение получил в начале 1980-х годов. Явился первым стандартным (де-факто) протоколом, обеспечивающим взаимодействие маршрутизаторов различных производителей. Использует алгоритм расчета вектора расстояния Беллмана-Форда.

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

Протокол OSPF [12,13,16] - один из самых "молодых" межсетевых протоколов. Разработан рабочей группой OSPF, сформированной весной 1988 г. Реализован пока не многими производителями. Использует алгоритмы состояния линии (Link-state) и "кратчайший путь первым". Протокол OSPF использует определяемую пользователем схему наименьшей стоимости, причем под стоимостью может пониматься не только стоимость в долларах, но и другие параметры качества сервиса (задержка, ширина полосы пропускания и др.), т.е. маршрутная метрика может перестраиваться под пользователя. При использовании алгоритма OSPF, обновление маршрутных таблиц происходит не периодически (как в протоколе RIP), 2 только при изменении состояния линии. В этом случае каждый маршрутизатор передает (лавинной маршрутизацией) свои характеристики другим маршрутизаторам, которые на основе этой информации изменяют свои маршрутные таблицы. Кроме того, при использовании протокола OSPF существует возможность объявлять независимые области маршрутизации.

Из приведенных характеристик протоколов видно, что протокол OSPF является новым и перспективным. В то же время, в модели сетевой архитектуры OSI не разработан стандартный протокол IS-IS. В этом случае можно было бы рассмотреть возможность переработки протокола OSPF под модель OSI и использования его в качестве протокола IS-IS. Но, наверное, не следует слишком увлекаться протоколом OSPF, так как его использование так же не решает вопросов автоматического управления конфигурацией и трафиком. Дело в том, что при использовании алгоритма OSPF маршрутизатор рассылает сведения о своих характеристиках тем маршрутизаторам, о существовании которых он знает [12], т.е. он не может автоматически включать в сеть новые маршрутизаторы.

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

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

Реализация программного обеспечения

Для создания целостной коммуникационной системы (в том числе мостов и маршрутизаторов), кроме реализации протоколов, необходимо [17]:

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

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

Природа межуровнеаых интерфейсов, уров-невого менеджмента, управления всеми ресурсами в OSI системе остаются "внутренним делом реализации", поэтому необходимо рассмотреть отображение архитектурных понятий (логический объект, точка SAP, архитектурный примитив, блоки SDU и PDU) на реализационные понятия (процесс, функция, событие, буфер и т.д.), а также определить функции менеджмента уровня и механизм их взаимодействия с протокольными объектами.

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

-    должна ли реализация поддерживать различ ные прикладные процедуры и сети либо она может быть оптимизирована для некоторого ограниченного использования, например, для работы только в одной ЛВС, либо для поддер жки конкретного рода прикладных процедур;

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

От решения этих вопросов зависит конкретный выбор:

-    программных модулей, реализующих один или несколько логических объектов;

-    процессной модели реализации: либо каждый модуль — отдельный процесс (модель "сер вер"), либо процесс - обработка одного входя щего или исходящего сообщения (модель "нить исполнения" (activity-thread)).

От реализации процессной модели в свою очередь зависит организация межуровневого интерфейса (для модели "сервер" — посредством межпроцессных сообщений, для модели "нить исполнения" посредством вызова процедур). Необходимо сказать, что в [17] утверждается, что для нижних уровней (которые реализуются в мосте и маршрутизаторе) больше подходит процессная модель "сервер".

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

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

Состояние международного рынка мостов и маршрутизаторов

В настоящее время в развитых странах вычислительные сети (computer network) перерастают в так называемые сети данных (data network). Т.е. вместо передачи данных между компьютерами используется подход, при котором все сетевые ресурсы становятся доступны всем сетевым пользователям. Упрощение использования локальных сетей обеспечит расширение их применения и рост их взаимосвязи. Так, в 1989г. в мире использовалось приблизительно 33 миллиона персональных компьютеров, 20% которых было связано в сети. В 1992 году ожидается использование 50-60 миллионов персональных компьютеров, 60% которых будут связаны в сети [18].

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

Например, по состоянию на март 1991 г. в мире насчитывалось 62 фирмы, производящие 159 различных межсетевых устройте (internetworking units) [19], из которых:

-    мостов - 119;

-    маршрутизаторов - 50;

-    мостов-маршрутизаторов (brouter - т.е. мос тов, выполняющих простейшие функции марш рутизации [16,19]) - 11. Некоторые из произво димых устройств межсетевой связи могут ис пользоваться в нескольких качествах, например как мост или как маршрутизатор. Цена межсе тевых изделий колеблется от 2000 долларов до 80000 долларов.

В обзорах межсетевых изделий [16,19] приводятся данные по количеству пакетов данных, пропускаемых через устройство межсетевой связи в секунду (paket per second - pps). Например, в обзоре [19] сведения по пропускной способности межсетевых продуктов колеблются в интервале 70-140 000 пакет/с. При этом не приводятся сведения для пакетов какой длины и для каких каналов данных получены эти значения. К таким сведениям необходимо относиться осторожно, если не известны условия получения этих результатов. При сравнении устройств по этому показателю необходимо учитывать разницу в:

-  длине пакетов данных [20,21];

а)  в различных сетях;

б) в одной и той же сети;

-    пропускной способности каналов данных [20];

-    методах подсчета [21].

Как было-отмечено выше, кроме зависимости пропускной способности межсетевого устройства от длины пакета данных и пропускной способности канала, существует зависимость значения пропускной способности устройства от методов ее расчета. Автор исследования [21] утверждает, что существуют теоретические пределы пропускной способности ретранслятора. Например, для сетей типа "Ethernet", работающих под управлением протоколов, соответствующих стандарту IEEE 802, максимальная пропускная способность ретранслятора для кадров длиной 64 байта будет 14 900 пакетов/с, а для кадров длиной 256 байт — приблизительно 4500 пакетов/с. Если же производитель утверждает, что пропускная способность его ретранслятора больше, то скорее всего она удвоена за счет учета и входящих и исходящих пакетов (что фактически одно и то же).

Что касается используемых в устройствах межсетевой связи протоколов, то в соответствии С приведенными в работе [16] данными по маршрутизаторам из 22 изделий 12 фирм 6 изделий поддерживают протоколы архитектуры OSI/ISO, что составляет примерно 27%.

В связи с развитием концепции "мира всеобщей коммуникабельности" вопрос о необходимости перехода к протоколам сетевой архитектуры OSI/ISO считается решенным, и в настоящее время активно обсуждается вопрос миграции протоколов других сетевых архитектур к протоколам сетевой архитектуры OSI [1]. Кроме того, вышеназванная концепция предполагает дальнейшее развитие межсетевых средств связи. Необходимо отметить, что мосты и маршрутизаторы скорее всего будут развиваться не только в аспектах улучшения своих реализационных характеристик (увеличение пропускной способности, уменьшение габаритов, легкость включения в сеть, удобство менеджмента и т.п.), но и в целевых аспектах.

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

Список литературы

1.           Знаменский Ю.Н., Чугунова Г.Н., Мультисетевой дос туп в супер-ЭВМ//В сб.: Технологии электронных ком муникаций. Т.З. - М., Экотрендз. 1991. - С.5-59.

2.           Technical And Office Protocol. Specification, Version 3.0. MAP/TOP Users Group, August 31, 1988, 282 p.

3.  IEEE Spectrum, v.26, N 1, 1989, p.44.

4.     Айхлер Э., Бенетт Г., Мосты, маршрутизаторы и шлю зы // Интерфейс- 1990.- N2.- С. 12-15.

5.           Stallings, W., Internetworking: A Guide for the Perplexed. Telecommunications v.23 N9, September 1989. pp. 25-30.

6.  3Com, NETBuilder, Ш/2000 and IB/2001. 1989, 7 p.

7.           Internet: Briges und Router erwejtern das Nets. LAN Magazine, v.3 Marz 1991, pp. 10-23.

8.           Mhshh И.А., Богатырев В.А., Кулешов А.П., Сети ком мутации пакетов. - М.: Радио и связь - 1986.- 407 с.

9.           RFC 1042. Postel, J.B.; Reynolds, J.K. Standard for the transmission of IP datagrams over IEEE 802 networks. 1988, February; 15 p. (Format: TXT = 3520! bytes) (Obsoletes RFC 948).

10. RFC 1058. Hedrick, C.L., Routing Information Protocol. 1988 June; 33 p. (Format: TXT = 93285 bytes).

11. RFC 113). Моу J. OSPF specification. 1989 October; 107 p. (Format: PS = 857280 bytes).

12. M"v J., СЫаррз, N.. OSPF; a New Dynamic Routing Standard, Network World, v.6, no.3I, 1989, p.36.

13. Moy J., OSPF; Next Generation Routing Comes to TCP/IP Networks. LAN Technology, v.6, N.4, April 1990, pp. 71- 79.

14. Comer D.E. Interne! work ing With TCP/IP. Vol.1: Principles, Protocols, and Architecture. Prentice Hall, Englewood Cliffs, New Jersey, 1991, pp. 427-439.

15. Harrison В., TCP/IP or OSI: Which Protocol Should You Speak? DEC Professional, v.9, N.4, 1990, pp.38-46.

16.       Reddy S., Pathfinders, Getting control of maze of net works. LAN Magazine, June 1990, pp. 101-111.

17.       Svobodova L., Implementing OSI Systems. IEEE Journal on Selected Areas in Communications, Vol. 7, No. 7, Septem ber, 1989, pp. 1115-1130.

18.       3Com, Corporation Background. April 1990, 11 p.

19.       Internet: Briges und Router erwejtem das Nets. LAN Magazine, v.3, Marz 1991, pp. 10-23.

20.       Spiner D., Internetwork now. LAN Technology, October, 1990, pp. 33-39.

21.       Weiss J., High-speed LAN internetworking. Networking Management, v.7, N12/89, pp. 66-72.