Принцип межоперационного интерфейса

Взаимодействие между блоками функций сети TMN

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

Рисунок 4.1 — Пример связи систем сетей TMN

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

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

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

Принцип межоперационного интерфейса

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

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

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

Отличие одного интерфейса от другого преимущественно определяется сферой деятельности управления, которая должна обеспечивать связь на этом интерфейсе. Это общее понимание круга операций называется " знание для раздельного управления (SMK) ". Оно включает в себя понимание информационной модели управляемой сети (обеспечиваемые классы объектов, функций и пр.), объекты обеспечения управления, обеспечиваемый прикладной контекст и др. Знание для раздельного управления гарантирует, что каждый конец интерфейса понимает точное значение сообщения, передаваемого другим концом (рисунок 4.2).

Управляющая система А управляет системой В непосредственно и системой С через систему В, используя SMK- от А к В и от В к С.

Рисунок 4.2 - Разделение знаний управления между системами

На рисунке 4.2 показано, что разделенная информация относится к взаимодействующей паре объектов. При этом знание SMK между функцией 1 (система А) и функцией 2 (система В) отличается от знания SMK между функцией 2 (система В) и функцией 3 (система С). Это не исключает наличие ряда общностей, в частности, на уровне системы В.

Как отмечалось ранее, когда функции или группы функций могут стать процессами, тогда опорные точки между этими процессами могут стать интерфейсами.

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

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

Рисунок 4.3 иллюстрирует то обстоятельство, что SMK не зависит от того, как они реализованы физически. Взаимодействие между функцией 1 и функцией 2 осуществляется с использованием SMK_А. Эти функции реализованы в одном физическом устройстве (устройство-1), поэтому SMK_А должно существовать, но оно будет неявно выражено, равно как и интерфейс, соответствующий опорной точке 1.

Рисунок 4.3 – Независимость знаний SMK от физической реализации

Как отмечалось ранее, когда функции или группы функций могут стать процессами, тогда опорные точки между этими процессами могут стать интерфейсами. Опорной точке 2 в физической реализации соответствует интерфейс 2.

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

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

Стандарт ISO 10164-16.2 определяет модель объектов управляющих знаний и классы таких объектов. Кроме того, определены функции работы с управляющими знаниями.

Имеются три типа управляющих знаний и, соответственно, три типа объектов, которые описывают эти знания:

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

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

-Знания об экземплярах (Instance Knowledge) обеспечивают информацию о конкретных экземплярах управляемых объектов, имеющихся в управляемой системе.

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

Дерево наследования (Inheritance Tree), называемое также деревом регистрации. Описывает отношения между базовыми и производными классами. Подчиненный класс наследует все характеристики суперкласса и дополняет их специфическими расширениями (дополнительными атрибутами, поведениями и действиями). Классы объектов OSI регистрируются в том же дереве, что и объекты MIB Internet. Дерево наследования может быть глобальным, то есть начинаться с корня, представляющего весь мир, или локальным, имеющим корень, соответствующий верхнему уровню объектов данной организации или сети. Все управляемые объекты OSI должны быть зарегистрированы в глобальном дереве ISO (в котором зарегистрированы объекты MIB-I, MIB-II, RMON MIB стандарта SNMP). Объекты, представляющие международные стандарты, регистрируются в международной ветви дерева, а частные модели, разработанные производителями систем управления, регистрируются в ветвях дерева, начинающихся с ветви private.

Дерево включений (Containment Tree). Описывает отношения включения управляемых объектов реальной системы.

Дерево имен (naming tree) определяет способ именования объектов в системе управления. Объекты OSI могут иметь имена нескольких типов: относительное отличительное имя (Relative Distinguished Name, RDN), отличительное имя (Distinguished Name, DN), иногда называемое полным отличительным именем (Full Distinguished Name, FDN), и локальное отличительное имя (Local Distinguished Name, LDN). Эти имена связаны с деревом включений, так как определяют имена объектов относительно включающих их объектов.[8]

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

Имя класса объекта позволяет обратиться к описанию класса и узнать полный список атрибутов этого класса или ссылку на родительский класс, у которого наследуются все или некоторые атрибуты. Имя экземпляра объекта дает информацию о принадлежности конкретного модуля или интерфейса определенному коммуникационному устройству. Классы управляемых объектов OSI должны определяться в соответствии со стандартом GDMO (Guidelines for the Definition of Managed Objects - Правила определения управляемых объектов), являющимся стандартом ISO.

В GDMO определяется несколько шаблонов — пустых форм, которые заполняются для описания определенного класса управляемых объектов. В шаблоне класса перечисляются комплекты свойств (PACKAGES), которые составляют класс. Шаблон комплекта свойств PACKAGE перечисляет Атрибуты, Группы атрибутов, Действия, Поведение и Уведомления, то есть свойства, сгруппированные для удобства описания класса объектов. Отношения наследования между классами описываются с помощью шаблона Связывание имен.

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

Заполненные шаблоны GDMO определяют представление класса и его свойств.

Заполнение шаблонов выполняется в соответствии с нотацией ASN.1. В отличие от стандартов SNMP, использующих только подмножество типов данных ASN.1, в GDMO и СMIР применяется полная версия ASN.1.

На основании правил GDMO определено несколько международных стандартов на классы управляемых объектов. Документы Definition of Management Information(DMI) и Generic Management Information (GMI) являются первыми определениями MIB на основе окончательной версии GDMO. Эти MIB могут рассматриваться как ISO-эквивалент для Internet MIB II, так как они создают основу для построения более специфических MIB. Например, DMI определяет класс объектов, называемый Тор, который является верхним суперклассом, — он содержит атрибуты, которые наследуются всеми другими классами управляемых объектов. Определены также классы объектов System и Network, занижающие верхние позиции в дереве наследования, так что любой агент должен понимать их атрибуты.

Описания классов управляемых объектов OSI регистрируются как в частных ветвях дерева ISO — ветвях компаний Sun, Hewlett-Packard, IBM и т. п., так и в публичных ветвях, контролируемых ISO или другими международными органами стандартизации.

В отсутствие одной регистрирующей организации, такой как IETF Internet, использование классов объектов OSI представляет собой непростую задачу.

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

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

4.3 Согласование контекста

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

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

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

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

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

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

В динамическом процессе согласования контекста обмен информацией знания SMK производиться через ассоциацию с помощью нескольких взаимодействий.

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

Области управления

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

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

управления в соответствии с географической, технологической или организационной структурами.;

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

- использование форм управления (например, обеспечение безопасности информации) соответствующим образом.

Для удовлетворения указанным выше требованиям управляемые объекты могут формироваться в группы. Управляемая группа объектов вместе с ее администратором составляют область управления, как показано на рисунке 4.4.

Рисунок 4.4 - Пример группы управляемых объектов в области управления

Между областями управления могут существовать взаимоотношения следующих типов:

- раздельные области управления;

- взаимодействующие области управления;

- перекрывающие друг друга области управления.

Перекрывающие друг друга области управления будут существовать в том случае, если один или несколько объектов одновременно принадлежат нескольким областям (смотри рисунок 4.5).

Рисунок 4.5 - Перекрывающие друг друга области управления

Пример взаимодействия между объектами и управляемыми ресурсами для элементов сети приведен на рисунке 4.6.

А - Агент; М- Администратор; R- Ресурсы; О - Управляемый объект

Рисунок 4.6 - Взаимосвязь между объектами и управляемыми ресурсами в случае элементов сети

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

4 Элементы сети TMN