Главная страница

Краткая характеристика протокола SNMP. Для поддержания работы


Скачать 21.53 Kb.
НазваниеДля поддержания работы
АнкорКраткая характеристика протокола SNMP
Дата29.11.2021
Размер21.53 Kb.
Формат файлаdocx
Имя файла4,1.docx
ТипПротокол
#285408

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

связи, поддерживающих различные стан-

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

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

Спецификации интерфейсов TMN осуществляются различными организациями, в том числе МСЭ-Т, ETSI, TMF. Спецификации интерфейсов, как правило, содержат формальное описание управляемого объекта с помощью выбранного метода описания и сценарий использования интерфейса. Иногда сценарий использования интерфейса TMN не входит в состав рекомендаций TMN. В спецификациях интерфейсов TMN указываются все ресурсы, доступные для управления и способы доступа к информации управления. Спецификация интерфейса TMN определяет функциональность интерфейса; в спецификации не содержится описание протоколов, которые используются для обмена информацией через интерфейс. Методология, которую нужно применять при проектировании и разработке интерфейсов TMN, описана в Рек. МСЭ-Т M.3020.

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

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

Существует три стандартных интерфейса TMN : интерфейс Q, интерфейс F и интерфейс X.

Интерфейс Q указывает, какая часть информации об объекте управления совместно используется и операционной системой и элементом сети. Другими словами, интерфейс Q определяет, какие телекоммуникационные ресурсы и операции элемента сети будут «видны» сети TMN в процессе управления, а какие ресурсы «не видны». Тот же интерфейс Q применяется на стыке OS – NE и на стыке OS – OS.

Интерфейс F позволяет соединить рабочую станцию WS и физические блоки TMN, которые поддерживают реализацию OSF и TF. Соединение осуществляется через сеть передачи данных DCN.

Интерфейс X поддерживает взаимосвязь TMN и других внешних систем, включая другие сети TMN. Интерфейс X используется для управления оказанием коммерческих услуг. Это возможно при наличии в корреспондирующих системах интерфейсов, взаимодействующих с TMN. C учётом факта передачи информации во внешнее окружение, уровень информационной безопасности для интерфейса X должен быть выше, чем для интерфейса Q. По аналогии c интерфейсом Q, интерфейс X определяет для внешних систем видимую часть «айсберга» сети TMN и порядок доступа к ресурсам сети TMN

Управление в TMN осу-ществляется с помощью информационной модели взаимодействия типа «менеджер – агент» (см. рис. 2.7 на следующей странице).

Считается, что программно-аппаратный комплекс, который выдаёт команды управления и принимает уведомления / сообщения / подтвер-ждения об исполнении команды, является менеджером.

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

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

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

Как только связь между менеджером и агентом установлена, может осуществляться обмен информацией. С помощью управляющих команд, которые оформляются в виде запросов, менеджер может потребовать у агента выполнить процедуры «Создать» (Create), «Удалить» (Delete), «Выполнить» (Action) в отношении управляемых объектов в целом, а так-же процедуры «Получить» (Get) и «Установить» (Set) в отношении атри-бутов управляемых объектов. Процедура описывает последовательность выполнения требуемой операции, включая последовательность обмена необходимыми запросами. Получив запрос на осуществлении той или иной процедуры, агент сначала на информационной модели ресурса, а затем – через функциональный интерфейс – непосредственно на обору-довании связи (телекоммуникационном ресурсе), выполняет необходи-мую операцию управления. Как правило, имена операций и процедур управления совпадают. Операция представляет собой описание требуе-мого действия.

После завершения операции агент изменяет содержимое информа-ционной базы управления и посылает сообщение о результатах менед-жеру. Агент выступает своего рода посредником между менеджером и управляемым оборудованием связи. При этом агент через функциональ-ный интерфейс непосредственно взаимодействует с управляемыми те-лекоммуникационными ресурсами (ТЭЗ, процессор, аппаратный модуль). Логическое описание ресурсов агент поддерживает с помощью информа-ционной модели ресурса. В информационной модели ресурса содержат-ся данные о рабочих характеристиках, на которые можно воздействовать или контролировать в процессе управления. С другой стороны, менеджер также поддерживает информационную модель управляемого ресурса. Поэтому информационные модели агента и менеджера в основном оди-наковы. Однако информационная модель менеджера включает модели нескольких ресурсов, например нескольких узлов или всех узлов сети связи. Кроме того, информация менеджера является «очищенной», нор-мализованной, упорядоченной. Это происходит благодаря действиям агента, который фильтрует поток данных в сторону менеджера, удаляя сведения о незначительных ошибках, искажения, повторах.

Сведения информационной модели, которую поддерживает агент, хранятся в базе данных информации управления (management information base, MIB). Менеджер также поддерживает MIB, но база данных менед-жера вторична по отношению к базе данных агента по причинам, которые были перечислены выше. Для обновления своей базы данных менеджер всегда запрашивает агента. В базе данных MIB информация управления логически упорядочена с помощью классов управляемых объектов и их атрибутов.

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

Все операции управления, осуществляемые в рамках модели «ме-неджер-агент», могут быть представлены в виде 4 примитивов - элементарных сообщений пользователей услуг управления т.е. агентов и менеджеров. Примитивы имеют соответствующие имена. Например, ус-луга по установлению соединения описывается примитивом с именем CONNECT, примитив услуги по передаче данных между менеджером и агентом имеет имя DATA. Примитивы используются следующим образом:

  1. Для выполнения операции на агенте, менеджер посылает управляю-щую команду в виде сообщения-запроса в виде примитива запроса (Request Primitive).

  2. Когда сообщение-запрос поступает агенту, запрос принимается как указание и инициирует на агенте примитив индикации (Indication Primitive), указывающий на необходимость вызова агентом необходи-мой процедуры.

  3. Агент выполняет действие, необходимое в рамках вызванной проце-дуры, посылает сообщение-ответ в виде примитива ответа (Re-sponse Primitive) в сторону менеджера.

  4. Сообщение-ответ принимается менеджером как сообщение-подтверждение в виде примитива подтверждения (Confirm Primitive).

Информационная модель управления TMN представляет собой упо-рядоченную конструкцию, которая включает информационную модель, технологию менеджер-агент и базы данных с общими (совместными) знаниями по управлению (shared management knowledge, SMK). Знания SMK могут быть разделены по нескольким узлам или операционным сис-темам TMN.

Выполнение операций Get, Cancel-Get (отменить получение), Create и Delete подтверждаются всегда; выполнение операций Set, Event-Report (сообщение о событии) и Action могут подтверждаться или не подтвер-ждаться.


написать администратору сайта