Способы организации управления. Элементы сети TMN. Услуги управления сети TMN, страница 3

Имя класса объекта позволяет обратиться к описанию класса и узнать полный список атрибутов этого класса или ссылку на родительский класс, у которого наследуются все или некоторые атрибуты. Имя экземпляра объекта дает  информацию о принадлежности конкретного модуля или интерфейса определенному коммуникационному устройству. Классы управляемых объектов 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 имеет место только в определенное время, и он происходит в течение некоторого заданного промежутка времени. Статический процесс может выполняться автономно до установления ассоциации (связного диалога) между интерфейсами управления. Он может быть также выполнен в диалоговом режиме как часть процесса установления связного контекста (ассоциации).