Применение суперЭВМ в научно-исследовательском учреждении можно рассматривать как возможность использования обобщенной в пределах учреждения уникальной вычислительной мощности для решения ресурсоемкой части исследовательских задач, например моделирования сложных объектов или систем автоматизации проектирования (САПР). В свою очередь САПР становится частью компьютеризированного учреждения, охваченного развитой коммуникационной сетью, вероятнее всего имеющей мультисетевую структуру [1]. Современная учрежденческая компьютерная сеть - это обширные вычислительные и коммуникационные ресурсы. Она состоит из больших ПЭВМ, мини- и микрокомпьютеров, рабочих станций и ПЭВМ, объединенных в локальные сети. А локальные сети с помощью мостов, маршрутизаторов и шлюзов могут быть соединены в сложные, географически распределенные муль-тисети. Наличие в сети персональных компьютеров (ПК) и рабочих станций делает реальным распределенную обработку информации а режиме клиент-серверов. При интегрировании сетей с различными передающими средами (Ethernet [2], Token Ring [3], ISDN [4], FDDI [5,6,7], Tl и т.д.) или с различными информационными потоками (например цифровые, речевые, образные и видеоданные) возникают неоднородные сети.

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

Требования, предъявляемые к системам сетевого менеджмента

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

• выполнять основной набор функций управления сетью;

•      поддерживать удобный пользовательский интерфейс;

•      соответствовать промышленным стандартам [8-13];

•      интегрироваться с продаваемыми продук тами;

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

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

1. Масштабируемость (Scalability) позволяет из менять свой размер от маленьких локальных до больших, географически распределенных сетей.

2.        Прозрачность (Transparency) не оказывает воздействия или оказывает приемлемое воздей ствие на производительность при нормальной работе сети.

3.        Интеграция с применениями (Applications integration). Должна быть "бесшовная" интегра ция системы сетевого менеджмента со множе ством типов передающих сред и трафиков. Эта интеграция также включает соглашения по пользовательскому и прикладному интерфей сам, по координации схемы базы данных.

4.        Поддержка множества распространителей (Multi-vendor support) окружает широкий спектр управляемых объектов, имеющихся у множест ва распространителей гетерогенных сетей, а также поддерживает механизм подстройки сис темы к ограниченным вычислительным воз можностям.

5.        Устойчивость (Robustness) должна быть из быточной и терпимой к ошибкам, иметь воз можность работы в критической ситуации и поддерживать восстановление после сбоя.

6.        Индивидуальность (Customizable). Пользова телям необходимо иметь возможность заказы вать управляющие функции для удовлетворе ния их индивидуальных задач и предпочтений.

Архитектура сетевого менеджмента фирмы 3Com

В качестве примера реализации системы сетевого менеджмента рассмотрим открытую архитектуру менеджмента фирмы 3Com ("3Com's Open Management Architecture - ОМА" ). Она основывается на открытом, расширяемом и гибком подходе к сетевому менеджменту. Архитектура ОМА - это набор нескольких взаимодействующих архитектур, работающих в рамках общей модели. Архитектура ОМА покрывает спектр управляющих и управляемых систем, управляющих информации и протоколов, прикладного управления и областей управления.

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

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

2.     География. Управление может осущест вляться по географически распределенной ЛВС, соединенной через повторители, мосты, марш рутизаторы и шлюзы фирмы 3Com или других производителей, поддерживающих стандартные протоколы сетевого управления.

3. Управляемые объекты. Основной упор дела ется на управление ЛВС-ориентированными объектами передачи данных (например повто рителями, мостами, маршрутизаторами, шлю зами, файловыми и терминальными серверами, рабочими станциями); поддержка объектов, ра ботающих с речевыми и видеоданными сейчас не планируется. Особые усилия были также вложены в такие прикладные сетевые пакеты, как "3 + Open LAN Manager" к "3 + Open Mail".

4. Технология. Ударение делается на системы, основанные на протоколах транспорного уровня архитектур XNS, TCP/IP и OSI/ISO, работаю щих в различных передающих средах (Ethernet, Token Ring, Broadband и FDDI). В области про токолов доступа к сети для управления в пер вую очередь внедряются протоколы CMIP, СМОТ, и SNMP. Совместимость с системой "NetView" очень важна и должна поддержи ваться с помощью шлюзов.

Модель менеджера /агента

Модель менеджера/агента в открытой архитектуре сетевого менеджмента фирмы 3Com вытекает из структуры системы менеджмента в архитектуре OSI. Эта структура определяет механизмы для контроля и управления объектами, которые производят обмен управляющей информацией между управляющими процессами прикладного уровня посредством протоколов управления. Взаимодействие между этими процессами концептуально симметрично в поддерживаемых услугах, но в данном обсуждении каждый процесс выполняет роль менеджера или агента. Основными компонентами модели менеджера/агента в архитектуре ОМА являются: человек-оператор, управляющие система и протокол и управляемая система.

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

Управляющий протокол (Managing protocol) поддерживает для управляющей системы возможность удаленного доступа к управляющей информации управляемой системы. Архитектура ОМА многоязычна, поскольку она использует несколько управляющих протоколов для доступа (SNMP, СМОТ). Как внутри, так и вне диапазона критичных путей управляющая система использует методы доступа, предоставляющие наибольшую защиту от ошибок. Результат действия управляющих протоколов -список услуг для управляющих функций (например восстановление управляющей информации, активизацию процедур и отчет о событиях). Из-за важности безопасности протоколов управляющего доступа, архитектура ОМА поддерживает системы безопасности (например аутентификацию, контроль доступа, шифрование) для защиты целостности информации в сети.

Управляемая система (Managed system). Управляемая система содержит агента (Agent) и управляющую информацию (Managed information). Агент - это представитель менеджера в управляемой системе, и он отвечает за действия в интересах менеджера при выполнении услуг для управления. Может быть так, что некоторые управляемые системы не будут иметь прямой связи с управляющей системой. Имеется несколько возможных причин для этого: управляющая система ограничена в использовании памяти или вычислительных ресурсов и не может токол доступа для управления системой не поддерживается менеджером; менеджер имеет специфические ограничения на безопасность; основной транспортный протокол не поддерживает связь между менеджером и агентом. В каждом из этих случаев архитектура ОМА поддерживает механизм доверенных лиц для доступа. Доверенное лицо работает в прозрачной манере для управления и преобразовании запросов менеджера в требуемые форматы, известные целевой системе. Доверенное лицо пересылает запросы целевой системе, используя некий механизм, который может быть не известным менеджеру. Отклик подобным образом посылается доверенному лицу, производящему обратное преобразование и передающему его менеджеру.

Второй компонент управляющей системы -управляющая информация. В архитектуре ОМА описываются два аспекта такой информации: структура управляющей информации (SMI — structure of management infonn'ation) и информационная база управления (MIB - management information base).

Структура SMI в архитектуре ОМА исполь зует объектно-ориентированные методы и абст рагирует управляющую информацию от набора управляемых объектов. Управляемые объекты группируются с подобными и родственными объектами в форме классов. Управляемый объект, существующий в конкретной управляе мой системе, определяется классом объектов, к которому он принадлежит. Управляемые объ екты представляются спецификацией их атри бутов, действий, которые могут быть выпол нены в отношении управляющего объекта, управляющих операций, разрешенные для уп равляемого объекта и событий, происходящих в управляемом объекте. Атрибут - это свойство или характеристика управляемого объекта (на пример число повторных передач — атрибут уп равляемого объекта в протоколах TCP). Управ ляемые объекты имеют связи с другими управ ляемыми объектами и могут содержать другие управляемые объекты, но атрибуты неделимы и ими можно манипулировать, как единым це лым. Управляемые объекты устанавливают также наполнения (Containment) и наследствен ные связи (Inheritance relationships). Напол нения в форме иерархии управляемых объек тов, рассматриваются как наполнение управ ляемых объектов с классом высшего объекта. Наследственные связи оказались удобным ме тодом для определения управляемых объектов, применяя принцип "наследования свойств". В структуре SMI также определяются поддержи ваемые типы данных, которые могут использо вать атрибуты, находящиеся в соответствии с действиями различных организаций по стандар тизации (например ISO и IETF (Internet Engineering Task Force)).         ^

База М18 в архитектуре ОМА использует структуру SMI для определения мира управляемых объектов. MIB представляет свбой концептуальную спецификацию или перечиеле-.ние управляемых объектов и не подразумевает какую-либо сортировку по физической памяти (память, файлы, базы данных). Иерархическая регистрция поддерживает идентификаторы объектов для всех известных управляемых объектов, которые составляют базу MIB. Идентификаторы объектов уникальны в пределах данного класса объектов и, объединившись с соответствующей информацией об объекте, представляют пример управляемого объекта, который может быть идентифицирован в операции управления. Требуемая информация об объекте получается из значений определенных атрибутов в иерархическом списке путей к интересующему объекту управления. База MIB является композицией нескольких стандартов (организаций IETF, ISO), определяющих информационные базы для менеджмента.

Архитектура менеджера

Архитектура менеджера в архитектуре ОМА описывает основу сетевого менеджмента, включающую в себя системное окружение и услуги для прикладного управления сетью. Они включают в себя общие услуги, которые необходимы в большинстве случаев, и услуги, необходимые для централизации и правильного функционирования. В концепции поддерживается уровень абстрагирования, позволяющий прикладным программам избегать рассмотрения деталей действительного аппаратно-программного окружения, в котором оно работает. Кроме того, имеется обширный список свободно распространяемых интерфейсов прикладного программирования {API — Application Programming Interface), которые поддерживают доступ к управляющим протоколам, базам данных и другим системным возможностям. Такая стратегия облегчает создание быстрого, эффективного и мобильного прикладного обеспечения для управления сетью как производства фирмы 3Com, так и других компаний. Основными компонентами этой платформы являются пользовательский интерфейс, операционная система, база данных, протоколы управления, транспортного и канального уровней и общие услуги.

В качестве прикладного пользовательского интерфейса используются системы "Presentation Manager" в операционной системе OS/2 и "X/Windows" (MOTIF) в системе UNIX. Оба интерфейса поддерживают работу пользователя с помощью, графических и оконных операций. Соглашения "смотри и осязай" облегчают работу с различными прикладными и операционнш-ми системами. Существуют два основных подхода для построения интерфейса пользователя: топографический и функциональный. Топографический подход основывается на карте вычислительной сети, а функциональный включает в себя систему вложенных меню и диалоговых ящиков, которые поддерживают интерфейс пользователя со всеми управляемыми системами.

Архитектура ОМА проектировалась так, чтобы поддерживать операционные системы OS/2 и UNIX с первоначальной ориентацией на OS/2 и UNIX с первоначальной ориентацией на OS/2. Поддержка распределенной файловой системы присуща обеим операционным системам. Файловая система, которая используется в архитектуре ОМА, включает в себя протоколы доступа к удаленным файловым системам, такие как протоколы SMB, NFS и FTAM [16].

База данных менеджера содержит всю информацию о конфигурации, производительности, а также контрольные данные. Отметим различия между базой MIB и базой данных. В MIB содержится вся управляющая информация по управляемым системам, охватываемым сетью. База данных менеджера - это специализированное физическое хранилище такой части из списка объектов базы MIB, какая необходима для функций управления. Некоторые управляющие функции кэшируют информацию из информационной базы MIB в базе данных, в то время как другие функции динамически обращаются к объектам базы MIB при необходимости, вызванной работой с сетью. База данных распределена в сети и располагается как в оперативной памяти, так и на диске. Она состоит из нескольких баз данных, основанных на единой схеме моделирования управляющей информации. Начальные реализации должны поддерживать ISAM (Indexed Sequental Access Method), SQL (Structured Query Language) и последовательный доступ. В дальнейшем также будут интегрированы объектно-ориентированные базы данных.

Управляющие протоколы делятся на два класса: собственно управляющие (management-specific) и двухточечные (point-to-point), например доступа к файлам, протоколы. Управляющие протоколы обычно ориентированы на транзакции и используются в форме запросов. Архитектура ОМА разработана для поддержки любого числа подобных протоколов, но изначально она была нацелена на протокол CMIP в сетевой архитектуре OSI, протоколы СМОТ и SNMP в архитектуре TCP/IP и интерфейс "Named Pipes" с протоколами SMB, как это определено в разработке "3 + Open LAN Manager" совместно фирмами Microsoft и 3Com. Двухточечные протоколы и протоколы доступа к файлам используются при передаче большого количества управляющих данных, таких как файлы конфигурации, файлы регистрации производительности или контрольные файлы. В этой категории архитектура ОМА должна поддерживать протокол SMB при работе с "3 + Open LAN Manager", протокол NFS при работе с сетью на основе архитектуры TCP/IP, н протокол FTAM - в сетях открытой архитек-гуры OSI. Для работы с оборудованием фирмы IBM для управляющего доступа должен использоваться продукт "3Com Maxess", который поддерживает фирменный протокол \PPC/LU6.2. Для терминального доступа для управления будут поддерживаться протоколы 'Telnet" (архитектура TCP/IP), VTP (Virtual rerminal Protocol) (архитектура OSI) и до-:ледовательный канал с кодировкой ASCII. Это юзволяет менеджеру организовывать терминальную сессию с управляемой системой и взаимодействовать с управляющим пользовательским интерфейсом, встроенным в управляемую систему. Некоторые системы фирмы 3Com поддерживают множество путей управляющего доступа. Такая избыточность обеспечивает возможность устойчивого управления.

Услуги транспортного и канального уровней обеспечивают доступ к системам передачи данных. На транспортном уровне поддерживаются архитектуры OSI, TCP/IP, SNA и XNS, на канальном - среды ETHERNET/IEEE 802.3 [2], TOKEN RING [3], синхронные и асинхронные последовательные каналы.

Первостепенные услуги общего применения -это функции работы с каталогами, файлами, защиты данных, загрузки системы и обработки событий. Функции работы с каталогами поддерживают распределенный механизм, который связывает объекты сети о соответствующими данными. Он включает в себя такие объекты, как пользователи и прикладные задачи. Функции работы с файлами предоставляются сетевыми устройствами с распределенным доступом к файлам для таких операций, как чтение информации о конфигурации. В архитектуре ОМА файловые операции поддерживаются протоколами SMB, NFS и FTAM [16]. Услуги безопасности поддерживают аутентификацию, авторизацию и работу с ключами. Услуги системной загрузки позволяют осуществлять удаленную загрузку образов выполняемых программ. Они основаны на протоколе системной загрузки IEEE 802.1, который поддерживает мультиядер-ную загрузку (Multicast loading), независимо от транспортного протокола (архитектуры TCP/IP, OSI ISO, XNS). Для загрузки через маршрутизаторы и шлюзы включены специальные помощники. Также поддерживается продукт "3 +Start" для загрузки, определенной рабочей группой. Планируется поддержка других протоколов загрузки, таких как BOOTP/TFTP для TCP/IP-сетей. Менеджер событий концентрируется на точке, где принимаются сообщения обо всех событиях, происходящих в поддерживаемых сетевых устройствах. В основном, это необходимо для учета и менеджера сбоев. Менеджер событий позволяет прикладным процессам указывать, какие события и в каких устройствах их интересуют. Архитектура ОМА поддерживает возможность удаленного доступа к менеджеру. Это осуществляется несколькими путями. Протоколы "Telnet" (архитектура TCP/IP) и VTP (архитектура OSI) позволяют менеджеру разрешать доступ с удаленного терминала через сеть. (Модемы должны поддерживать двунаправленный доступ). В обоих этих методах доступа командная строка ориентируется интерфейсом на отображение управляющих функций. Это позволяет системам с ограниченными вычислительными возможностями иметь многофункциональную дисплейную станцию с процессором и быстрой памятью для прикладных задач, базирующихся на удаленных сетевых услугах (например станцию "3Server/500" фирмы 3Com).

Архитектура агента

Прикладная архитектура

Архитектура агента включает в себя стек транспортных протоколов (Transport protocol stack), протокол сетевого управляющего доступа, прикладной процесс управления системой (System Management Application Process -SMAP) и объекты управления. Вообще, агент необходим для приема пакетов с запросами сетевого менеджмента, разбора запросов, доступа к запрошенной управляющей информации в системе, формирования пакета ответа и пересылки ответа запросившему менеджеру. Стек транспортных протоколов необходим для приема запросов и отправления ответов. Протокол управляющего доступа служит для равноправного обмена между менеджером и агентом, а также для перевода из формата и в формат протокольного пакета. Протокол SMAP работает как системно-зависимый диспетчер, который гарантирует, что запросы будут выполнены определенными объектами управления и отклики будут возвращены соответствующим запросившим их менеджерам. Объекты управления обеспечивают доступ к требуемой информации.

Как транспортный протокол, так и протокол управляющего доступа могут быть неодинаковыми в различных управляемых системах. Системы с архитектурой OSI используют протокол CMIP, а с архитектурой TCP/IP протоколы СМОТ или SNMP. При работе в среде протоколов на основе системы "NetBIOS" также может быть использован доступ к определенным управляющим объектам на рабочих станциях и серверах.

Объекты управления существуют для различных областей, например: объекты управления уровнем для определенных уровней протокола, объекты управления системой для основных системных параметров или объекты прикладного управления для параметров, определенных прикладными процессами, такими как система "З + Ореп LAN Manager". Объекты управления являются действующей частью и интегрируются с объектом, которым они управляют; используют системно-зависимый механизм для взаимодействия с процессом SMAP. Агенты также предназначены для сообщения о происходящих событиях соответствующему менеджеру. При инициализации системы управляемая система конфигурируется таким образом, что определенные менеджеры принимают сообщения о конкретных событиях. События определены в информационной базе MIB и могут быть разрешены или запрещены. Объекты управления служат для регистрации событий и пересылки отчета о них процессу, поддерживаемому протоколом SMAP, для переадресации их соответствующему менеджеру. Чтобы предотвратить лавинную генерацию событий в сети в определение событий, включается соответствующий механизм.

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

Услуги общего применения, которые являются частью основы менеджера архитектуры ОМА, развиваются, используя архитектуру клиент-серверов, Например, интерфейс управления сетью является библиотекой задач, которые связывают с помощью протокола межпроцессного взаимодействия в сети протокол SMAP и стек протоколов управления сетью. Это позволяет серверу управляющего доступа к сети поддерживать много клиентов для прикладного управления сетью на различных машинах. В результате сохранение важных данных для системы клиента происходит в системе сервера вследствие множественного стека протоколов управления сетью. Архитектура ОМА также поддерживает полный список соглашений для упрощения интерфейса и обмена данными, включения новых прикладных задач и обеспечивает удобный интерфейс с пользователем для поиска.

Управление доменами и шлюзами

Размеры и сложность вычислительных сетей делают необходимым логическое деление сети на несколько более простых в управлении частей. Конечный результат этого - образование доменов. В архитектуре ОМА домен - это группа управляемых объектов с единой политикой управления (Management policy). Как утверждалось ранее, управляемый объект - это абстрагированная управляющая информация, относящаяся к реально существующему объекту. Управляемые объекты, составляющие домен, не обязаны быть одного типа. Свойства и атрибуты очерченных объектов в домене определяют его тип. Может быть несколько типов доменов в сети. Домены ассоциируются с менеджером, производящим операции управления и контроля в соответствии с определенными правилами доступа. Сами менеджеры являются объектами, которые могут входить в домены.

Также конкретный домен может иметь несколько менеджеров.

Существующие связи доменов с другими доменами базируются на их взаимодействии с менеджерами. Эти взаимосвязи могут быть нескольких типов: расчленения, пропуска, вложенности и косвенных связей. Расчленение возникает, когда разделяется объект, включенный в два домена. Пропуск используется, когда управляемый объект находится в списке объектов более чем одного домена данного типа. Вложенные объекты возникают, когда домены X и У одного типа, и все объекты домена X содержатся внутри домена Y. Менеджер Y может иметь как полные, так и ограниченные управление и контроль над объектами домена X, Наконец, косвенные связи возникают при попытке менеджера домена X управлять объектом домена Z косвенно, через менеджер Y.

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

Рассмотренные принципы построения открытой архитектуры сетевого менеджмента фирмы 3Com в основном справедливы и для других систем.

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

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

2.      ANSI/IEEE 802.3. Local Area Networks - Carrier Sence Multiple Access with Collision Detection (CSMA/CD) - Access Method and Physical Specifications. 1985, 144 p.

3.      ANSI/IEEE 802.5. Token Ring Access Method and Physical Layer Specifications. 1985, 89 p.

4.      CCITT Draft reccomndation I.I21 - Broadband aspects of ISDN; // CCITT, TD49, Seul, Korea, feb - 1986.

5.      ISO/IEC 9314-1. Information processing systems - Fiber Distributed Data Interface (FDDI) - Part 1: Token Ring Physical Layer Protocol (PHY), 1990.

6.  ISO/IEC 9314-2. Information processing systems - Fiber Distributed Data Interface (FDDI) - Part 2: Token Ring Media Access Control (MAC), 1990.

7.      ISO/IEC 9314-3. Information processing systems - Fiber Distributed Data Interface (FDDI) - Part 3: Token Ring Physical Layer Medium Dependent (PMD), 1990, 47 p.

8.      RFC 793. Postel, J.B. Transmission Control Protocol. 1981 September; 85 p. (Format: TXT = 177957 bytes).

9.      RFC 791. Postel, J.B. Internet Protocol. 1981 September; 45 p. (Format; TXT = 97779 bytes) (Obsoletes RFC 760).

10.       RFC 1009. Braden, R.T.; Postel, J.B. Requirements for Internet gateways. 1987 June; 55 p. (Format: TXT = 128173 bytes) (Obsoletes RFC 985).

11.       ISO 7498. Information Processing Systems - Open Systems Interconnection - Basic Reference Model. 1984, 40 p.

12.       RFC 1189. Warner, U.S.; Besaw, L.; LaBarra, L.; Handspicker, B.D. Common Management Information Services and Protocols for the Internet (CMOT) and (CMIP). 1990 October; IS p. (Format: TXT = 32928 bytes) (Obsoletes RFC 1095).

13.       RFC 1157. Case, J.D.; Fedor, M.; Schoffstall, M.L.; Davin, С Simple Network Management Protocol (SNMP). 1990 May; 36 p. (Format: TXT = 74894 bytes) (Obsoletes RFC 1098).

14.       RFC 1095. Warner, U.S.; Besaw, L. Common Management Information Services and Protocol over TCP/IP (CMOT). 1989 April; 67 p. (Format: TXT = 157506 bytes) (Obsoleted by RFC 1189).

15.       3Com's Open Management Architecture. 3Com Corp., 1990. 12 p.

16.       ISO 8571. Information Processing Systems - Open Systems Interconnection - OSI - File Transfer, Access and Management. Part 1-4. 1983, 202 p.