книги / Современные принципы и технологии управления инфокоммуникационными сетями.-1

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

Например, класс объектов eventLogRecord, описываемый в стандарте ISO 10165-2 (Х.721), включенный в раздел классов управляемых объектов managedObjectClass (3), и зарегистрированный под номером 5, будет иметь следующий OID: {joint-iso- ccitt(2)ms(9)smi(3)part2(2)mana-gedObjectClass (3) eventLogRecord (5)}, в числовом выражении: 2.9.3.1.3.5.

Атрибут eventType класса eventLogRecord, включенный в раздел атрибутов attribute (7) и зарегистрированный под номером

14, будет иметь OID: {joint-iso-ccitt(2)ms(9)smi(3)part2(2)attri- bute(7)event-Type(14)} – 2.9.3.2.7.14. Таким образом, появляется возможность использовать атрибут этого типа в других классах.

Рекомендации ITU-T регистрируются в ветви дерева ccitt (0) recommendation (0). Серии рекомендаций A-Z пронумерованы от 1 до 26 (серия М имеет номер 13). Нумерация в пределах каждой серии выполняется в соответствии с номером рекомендации. В каждой рекомендации, где описываются классы, для информационной модели выделен раздел – informationModel (0), в котором регистрируется вся информация управления. Таким образом, классы объектов, определенные в рекомендации M.3100 (Generic Network Information Model) регистрируются с OID: {ccitt (0) recommendation (0) m (13) gnm (3100) informationModel (0) managedObjectClass (3) …} – 0.0.13.3100.0.3. ….

Объекты стандартов Европейского института стандартов те-

лекоммуникаций (European Telecommunications Standards Institute – ETSI) регистрируются в ветви ITU-T identified-organization (4) под номером 0: {ccitt (0) identified-organization (4) etsi (0) ets304 (304)…} – 0.4.0.304. ….

Структура включения

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

41

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

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

Основныепринципысхемы именования экземпляров объектов:

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

2.Относительное отличительное имя (Relative Distinguished Name, RDN) соответствует короткому имени, которое однозначно определяет объект среди множества других объектов, подчиненных тому же родительскому объекту. RDN определяется атрибутом именования объекта. Значение этого атрибута должно быть уникальным среди всех объектов, подчиненных тому же родительскому объекту. Например, для дерева, изображенного на рис. 2.8, атрибут именования управляемого объекта logRecord2 – {logRecordId = 2}, где logRecordId – это имя атрибута, а 2 – это значение атрибута.

3.Отличительное имя (Distinguished Name, DN), иногда называемое полным отличительным именем (Full Distinguished Name, FDN) представляет собой последовательность RDN-имен, начинающуюся в вершине глобального дерева имен, т.е. дерева,

описывающего некоторую		глобальную	сеть.	Например,
DN управляемого	объекта	system –	{systemTitle =		=
TransportNetworks},	и DN управляемого объекта			logRecord2	–

{systemTitle = TransportNetworks, logId = 0, logRecordId = 2}.

42

4. Локальное отличительное имя (Local Distinguished Name, LDN) – это последовательность RDN-имен, но начинающаяся не в глобальном корне, а в корне дерева имен локальной системы управления, отвечающей за часть глобального дерева имен данной сети. Например, для дерева на рис. 2.8. LDN управляемого объекта logRecord2 – {logId = 0, logRecordId = 2}.

system

systemTitle = TransportNetworks

network 0

network 1

log 0

networkId = 0

networkId = 1

logId = 0

sdhNE 0

sdhNE 1

logRecord 0

logRecord 1

logRecord 2

sdhNEId = 0

sdhNEId = 1

logRecordId = 0

logRecordId = 1

logRecordId = 2

Рис. 2.8. Дерево включений

Следует отметить, что имя экземпляра управляемого объекта (значение атрибута именования) создается при создании экземпляра. Эти имена не могут быть доступны для их изменения.

На рис. 2.8 показано дерево включений. В этом примере экземпляр объекта system – корень локального дерева включений и содержит два экземпляра объекта network и один экземпляр объекта log. Объект network 0 содержит два экземпляра объекта sdhNE (моделируется сеть технологии SDH, состоящая из двух сетевых элементов). Объект log 0 содержит три экземпляра объекта logRecord (моделируетя журнал событий с тремя записями). Для каждого экземпляра обозначены имя класса объекта и его относительное отличительное имя. Фактически данное дерево соответствует системе управления (объект system), содержащей две сети (объекты network), одна из которых содержит два сетевых элемента (объекты sdhNE) и службу ведения журналов событий (объекты log и logRecord). Дерево включений также называется деревом имен, так как отличительное имя управляемого объекта получено из его позиции в дереве включений.

43

2.2.2.3. Операции системного управления

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

Управляющие операции делятся на две категории: операции, которые работают с атрибутами объектов, и операции, которые работают с объектом в целом.

Атрибутоориентированные операции

Следующие команды могут быть посланы объекту и применены к одному и более атрибутам этого объекта:

–Получить значение атрибута. Читает значение атрибута (или список значений) и возвращает это значение, которое должно быть прочитано, или ошибку, если значение не было прочитано.

–Изменить значение атрибута.

–Изменить значение атрибута на заданное по умолчанию. (Значение по умолчанию определяется в спецификации класса объекта.)

–Добавить новое значение в списке возможных значений атрибута.

–Удалить значение из списка значений атрибута.

Объектно-ориентированные операции

Следующие операции применяются к управляемым объек-

там как к целым частям:

–Создать. Создает и инициализирует экземпляр класса управляемого объекта.

–Удалить. Удаляет экземпляр класса управляемого объекта.

–Действие. Управляемый объект выполняет определенное действие и возвращает результат.

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

44

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

2.2.2.4. Правила определения управляемых объектов

Классы управляемых объектов должны определяться в соот-

ветствии со стандартом ISO 10165-4 (X.722) Guidelines for the Definition of Managed Objects (GDMO) [5] – правила определения управляемых объектов. GDMO определяет десять шаблонов (templates) – пустых форм, которые заполняются для описания определенного класса управляемых объектов.

При определении класса управляемого объекта используется шаблонMANAGED OBJECT CLASS, внутрикоторогоуказывается:

–имя класса;

–какой класс является родительским;

–основные комплекты свойств (PACKAGE) и дополнительные комплекты (CONDITIONAL PACKAGE), которые используются при определенных условиях;

–OID, под которым зарегистрирован этот класс.

В шаблоне комплекта свойств PACKAGE перечисляются свойства класса объекта:

–поведение (BEHAVIOUR) – описывает реакцию объекта на примененное к нему действие;

–атрибуты (ATTRIBUTES) и группы атрибутов (ATTRIBUTE GROUPS) – определяют параметры объекта, которые можно читать

иузнавать изних о состоянииобъекта;

–действия (ACTIONS) – описывают возможные управляющие воздействия, которые допускаются применять к данному объекту;

–уведомления (NOTIFICATIONS) – составляют набор сообщений, которые генерирует объект по своей инициативе.

Кроме свойств объекта, каждый комплект имеет метку (имя)

идолжен быть зарегистрирован. Для каждого свойства, в свою очередь, есть свои шаблоны.

45

В свойствах <атрибуты>, <действия> и <уведомления> присутствует раздел параметры (PARAMETERS), для которого есть свой шаблон. Раздел PARAMETER используется (в зависимости от контекста конкретного свойства, в котором он указан) для отождествления определенного события, например ошибки, с конкретными типами действий (уведомлений).

Шаблон связывания имен (NAME BINDING) определяет отношения наследования между классами (указывается суперкласс и подчиненные классы) и определяет условия создания и удаления экземпляров этого класса.

Заполнение шаблонов выполняется в соответствии с нотацией языка абстрактного синтаксиса (Abstract Syntax Notation One – ASN.1). Нотация служит для установления однозначного соответствия между терминами, взятыми из стандартов, предназначенных для использования людьми и теми данными, которые передаются в коммуникационных протоколах аппаратурой. В результате документация MIB может точно и механически транслироваться в форму кодов, характерных для сообщений протоколов. Нотация ASN.1 поддерживает базовый набор различных типов данных, таких как целое число, строка и т.п., а также позволяет конструировать из этих базовых типов составные данные: массивы, последовательности, структуры. Существуют правила трансляции структур данных, описанных на ASN.1,

вструктуры данных языков программирования, например С++. Отличие связки GDMO/ASN.1 от универсальных объектноориентированных языков программирования C++, Java состоит

втом, что GDMO/ASN.1 предназначены только для описания объектов и структур данных, они не могут описывать алгоритмы.

Вкачестве примера использования GDMO можно привести фрагмент описания класса system из рекомендации X.721:

system MANAGED OBJECT CLASS -- объявление класса system

DERIVED FROM top; -- наследование от класса top CHARACTERIZED BY

systemPackage PACKAGE -- набор(пакет) пере-

менных

46

ATTRIBUTES systemId GET, systemTitle GET, operationalState GET, usageState GET;;;

REGISTERED AS {joint-iso-ccitt ms(9) smi(3) part2(2) managedObjectClass(3) 13}; -- назначение OID для класса system

Для атрибутов(параметров) указывается операция (услуга CMISE – подробнее об этом см. в подразд. 2.2.5), которая может быть использована для обращения к атрибуту.

Существуют инструменты (GDMO/ASN.1 Tools), позволяющие ускорить процесс написания MIB. Используя технологию визуального программирования, инструменты облегчают проектирование и разработку MIB, беря на себя рутинные операции по выбору шаблонов, установлению связей, наследования и т.п. с графическим представлением создаваемой структуры.

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

2.2.3. Организационные аспекты системного управления

Организационные аспекты определены распределенным характером управления OSI. Кроме упоминавшейся ранее модели взаимодействия «агент–менеджер» к организационным аспектам относятся понятия политики, доменов и юрисдикций управления.

Следует отметить, что в первом варианте стандарта «Обзор системного управления OSI» ISO 10040 (X.701) [3] было дано определение только доменов управления. Понятия политики и юрисдикций управления появились только во втором варианте стандарта, который был опубликован в 1997 г.

47

Домен управления – группа управляемых объектов, объединенных по определенному принципу (географическому, технологическому, функциональному: безопасность, учет ресурсов

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

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

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

Юрисдикция управления – это представление отношений между политикой управления и доменом управления. Организационные требования юрисдикции регламентируют управление юрисдикциями управления и определяют применение политики или множества политик к группе управляемых объектов или определенному управляемому объекту.

Юрисдикция управления связывает политику управления и домен управления и позволяет применить семантику политики управления к членам домена (рис. 2.9).

Политика	Домен
управления	управления
Юрисдикция
управления	Члены домена
Семантика политики	(управляемые
	объекты)

Рис. 2.9. Архитектурная модель организационных аспектов управления

48

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

2.2.4. Функциональные аспекты системного управления

Функциональные области управления, определенные в структуре управления OSI, описывают достаточно широкий круг задач сетевого управления. Каждая из этих областей должна быть реализована с использованием функций системного управления (System Management Functions – SMFs). Функции системного управления описаны в группе стандартов ISO 10164-xx (по нумерации ITU-T для описания функций выделен диапазон номеров с X.730 по X.799). Разработка новых функций продолжается и в настоящее время. На текущий момент определено 36 функций.

Каждая функциональная область обеспечивается несколькими функциями. С другой стороны, отдельные функции могут использоваться сразу в нескольких функциональных областях управления. Например, функция «отчет о событии» (event-report) может быть применима ко всем функциональным областям. Ниже перечислены основные функции системного управления:

1.Управление объектом (Object Management – X.730). Обес-

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

иизменение его атрибутов.

2.Управление состоянием (State Management – X.731). Оп-

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

3.Управление связями (Relationship Management – X.732).

Определяет модель для представления и управления взаимоотношениями между управляемыми объектами. Обеспечивает службы поддержки модели.

49

4.Отчет об авариях (Alarm Reporting – X.733). Определяет сигналы аварий, уведомления, используемые для отчета об авариях, категории и приоритетность сообщений.

5.Управление отчетом о событиях (Event Report Management – X.734). Поддерживает контроль отчета о событиях, включая спецификацию получателей отчетов, определение формы отчетов, спецификацию критериев для генерации и распространения отчетов, параметрыфильтрациисообщений.

6.Контроль журналов событий и учета (Log Control – X.735). Обеспечивает создание журналов, правила и механизмы создания, хранения и удаления учетных записей в журналах, определяет критерии для журнализации.

7.Отчет о сигналах безопасности (Security Alarm Reporting – X.736). Определяет сигналы тревоги, связанные с безопасностью,

иуведомления, используемые для отчетов о них.

8.Ведение аудита безопасности (Security Audit Trail – X.740). Определяет типы отчетов о событиях, которые должны быть включены в журнал для оценки безопасности.

9.Контроль доступа (Access Control – X.741). Поддерживает контроль доступа к информации управления и операциям управления.

10.Счетчик учета (Accounting Meter – X.742). Необходим для учетаиустановкиограниченийиспользованияресурсовсистемы.

11.Мониторинг нагрузки (Workload Monitoring – X.739).

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

12.Управление тестированием (Test Management – X.745). Поддерживает управление тестовыми процедурами: конфиденциальными и диагностическими.

13.Накопление статистической информации (Summarization – X.738). Определяет параметры сбора статистики и отчетности о накопленной информации.

В качестве примера описания функций, рассмотрим одну из базовых функций – «Управление состоянием объекта» (State Management – X.731). Функция определяет три атрибута (переменных) состояния объекта:

50