|
СЕТЕЗАВИСИМЫЕ
И СЕТЕНЕЗАВИСИМЫЕ УРОВНИ
Функции всех
уровней модели
OSI могут быть отнесены к одной
из двух групп: либо к функциям,
зависящим от конкретной технической
реализации сети, либо к функциям,
ориентированным на работу с
приложениями.
Три нижних
уровня — физический,
канальный и
сетевой —
являются сетезависимыми, то есть
протоколы этих уровней тесно связаны
с технической реализацией сети и
используемым коммуникационным
оборудованием. Например, переход на
оборудование FDDI означает полную
смену протоколов физического
и канального
уровней во всех узлах сети.
Три верхних
уровня — прикладной, представительный
и сеансовый —
ориентированы на приложения и мало
зависят от технических особенностей
построения сети. На протоколы этих
уровней не влияют какие бы то ни было
изменения в топологии сети, замена
оборудования или переход на другую
сетевую технологию. Так, переход от
Ethernet к высокоскоростной технологии
100VG-AnyLAN не потребует никаких изменений
в программных средствах, реализующих
функции прикладного, представительного
и сеансового
уровней.
Рисунок.
Сетезависимые и сетенезависимые
уровни модели OSI.
Транспортный
уровень является промежуточным, он
скрывает все детали функционирования
нижних уровней от верхних. Это
позволяет разрабатывать приложения,
не зависящие от технических средств
непосредственной транспортировки
сообщений.
На рисунке
показаны уровни модели
OSI, на которых работают различные
элементы сети. Компьютер с установленной
на нем сетевой ОС взаимодействует
с другим компьютером с помощью
протоколов всех семи уровней. Это
взаимодействие компьютеры осуществляют
опосредованно, через различные
коммуникационные устройства:
концентраторы,
модемы, мосты,
коммутаторы,
маршрутизаторы,
мультиплексоры. В зависимости от
типа коммуникационное устройство
может работать либо только на
физическом уровне
(повторитель),
либо на физическом
и канальном
(мост), либо на физическом,
канальном и
сетевом, иногда
захватывая и транспортный уровень
(маршрутизатор).
Рисунок.
Соответствие функций различных
устройств сети уровням модели OSI.
Модель
OSI представляет хотя и очень
важную, но только одну из многих
моделей коммуникаций. Эти модели и
связанные с ними стеки
протоколов могут отличаться
количеством уровней, их функциями,
форматами сообщений,
службами, поддерживаемыми на верхних
уровнях, и прочими параметрами.
Функции, ассоциированные с протоколами
Прикладного уровня позволяют нашей
социальной сети взаимодействовать
с лежащей в основе сетевой
инфраструктурой. Когда мы открываем
веб браузер или окно программы
мгновенных сообщений, приложение
запускается и программа загружается
в память устройства, на котором
выполняется. Каждую выполняемую
программу, загруженную на устройстве,
называют процессом.
На Прикладном
уровне существует две формы программ,
обеспечивающих доступ к сети:
приложения и службы. Сетевые
Приложения. Приложения – это
программы, используемые людьми для
коммуникации по сети. Некоторые
приложения конечного пользователя
являются сетевыми, т.е. они реализуют
протоколы Прикладного уровня и
способны осуществлять коммуникацию
напрямую с более низшими уровнями
стека протоколов. Клиенты электронной
почты и веб браузеры являются
примерами этих типов приложений.
СЛУЖБЫ ПРИКЛАДНОГО УРОВНЯ
Другие программы
нуждаются в содействии служб
Прикладного уровня для использования
сетевых ресурсов, например передача
файлов или буферизация (спулинг)
сетевой печати. Будучи прозрачными
для пользователя, эти службы являются
программами, которые взаимодействуют
с сетью и подготавливают данные для
передачи. Различные типы данных –
будь то текст, графика или видео –
требуют различных сетевых служб для
гарантии того, что они будут
соответствующим образом подготовлены
для обработки функциями, работающими
на более низших уровнях модели OSI.
Каждое приложение
или сетевая служба применяет
протоколы, которые определяют
используемые стандарты и форматы
данных. Без протоколов сеть
данных не имела бы
общего способа для форматирования
и направления данных. Чтобы понять
функцию различных сетевых служб,
необходимо познакомиться с лежащими
в их основе протоколами, которые
управляют их работой.
Сетевая
служба — вид сервиса,
предоставляемого сетью.
Сервис — процесс
обслуживания объектов.
Сервис предоставляется пользователям,
программам,
системам,
уровням,
функциональным
блокам и другим объектам сети.
Наиболее распространенными видами
сервиса являются:
хранение
данных и поиск
информации;
передача
сообщений
и блоков
данных;
электронная
почта и речевая
почта;
организация
и управление диалогом
партнеров;
предоставление
соединений;
проведение
сеансов
взаимодействия прикладных
процессов.
Сервис
осуществляют сетевые
службы. В последние годы особенно
быстро развивается видеосервис:
видеодиалог, видеоконференции,
видеобиблиотеки, видеопочта,
телевидение.
В телефонии
предоставляется так называемый
дополнительный
сервис.
В
базовой
эталонной модели взаимодействия
открытых систем объекты N-уровня
предоставляют сервис объектам N+1
уровня. Он осуществляется благодаря
передаче между уровнями специальных
блоков данных, именуемых сервисными
примитивами.
Благодаря этому, прикладные процессы
в своем взаимодействии используют
суммарный сервис, предоставляемый
всеми семью уровнями области
взаимодействия.
Сетевая
служба может располагаться на
сеансовом
уровне, представительном
уровне, прикладном
уровне и предоставлять сервис
пользователям
и прикладным
процессам. Современная сетевая
служба, как правило, располагается
на прикладном
уровне. Вместе с этим, нередко она
охватывает также представительный
уровень. Во всех случаях сетевая
служба не зависит от типа используемой
коммуникационной сети.
Одной
из первых сетевых служб явилась
телефония.
Первоначально для ее работы создавалась
специальная телефонная
сеть. Аналогично этому, для
телевидения
использовалась телевизионная
сеть. Протоколы
обеих сетей были предназначены для
одного вида сервиса. Позже к этим
сетям стали подключать и компьютеры.
Однако, между компьютерами и сетью
ставились модемы,
чтобы сигналы
первых соответствовали стандартам
последних. С созданием современных
многоцелевых коммуникационных
сетей ситуация резко изменилась.
Различные сетевые службы стали
опираться на общие этажерки протоколов.
Любая
сетевая служба, используя сервис,
предоставляемый областью
взаимодействия, обеспечивает
связь прикладных процессов,
расположенных в различных абонентских
системах сети. В свою очередь,
служба выполняет сервис, который
необходим для прикладных процессов.
Например управление файлами,
сообщениями.
Поэтому сетевые службы являются
платформами,
на которых располагаются прикладные
процессы. Это позволяет создавать
Базы
Данных (БД), Базы
Знаний (БЗ), другие разнообразные
службы, например, службы
коммерческой информации. Последние
определяются стандартами ISO,
ITU,
а также крупных фирм - производителей
систем.
В
сети работает значительное число
различных служб. Все большее их число
определяется стандартами Международной
Организации Стандартов (МОС):
сетевая
служба справочной информации DS*;
сетевая
служба обмена электронными данными
EDI;
сетевая
служба управления файлами и доступа
к ним FTAM;
сетевая
служба передачи заданий и управления
их выполнением JTM;
сетевая
служба электронной почты MHS/MOTIS;
сетевая
служба обработки и передачи документов
ODA;
сетевая
служба управления сетью NMS;
сетевая
служба обеспечения стандартных
форм работы терминалов VT.
Целям
распределенной
обработки данных служит прикладная
служба. Появились также сетевые
службы, определяемые фирменными
стандартами, например, сетевая
служба MMS, служба
глобального соединения, сетевая
служба ENS.
Особыми
видами служб являются электронная
библиотека, телетекст,
видеотекст,
факсимильная
связь.
Сетевая
служба DS*. Сетевая
служба DS* - сетевая
служба справочной информации.Сетевая
служба DS*
располагается на прикладном
уровне и является вспомогательной,
ибо предназначена для создания
сетевой
службы каталогов, выдачи справок
и отображения адресов
сетевых объектов
(служб, Баз
Данных (БД), прикладных
процессов) в физические.
Она
имеет базу данных, которая расположена
в одной либо нескольких абонентских
системах. В последнем случае
информационная база состоит из
группы агентов сервиса (AC), расположенных
в различных системах и взаимодействующих
друг с другом в соответствии со
специальным протоколом.
Сетевая
служба EDI. Сетевая
служба EDI — сетевая
служба обмена электронными данными.
Технология EDI,
именуемая также Сервисом электронных
писем ELS,
представляет собой стандартный и
не зависимый от платформ
способ обмена деловыми документами
(письмами, предложениями на поставку,
заказами, счетами, накладными и т.д.)
между предприятиями, фирмами,
учреждениями. Она является важным
направлением в электронном
маркетинге, ибо обеспечивает
возможность заключения сделок с
помощью компьютеров
и отслеживания поставок товаров.
Располагается
EDI на прикладном
уровне. Средой, в которой используется
EDI, часто является сетевая
служба MHS/MOTIS. Между тем, EDI не зависит
от MHS/MOTIS
и может использовать любую другую
среду передачи сообщений.
EDI работает не только с текстами,
но и с неподвижными изображениями,
видеофильмами
и фрагментами звука.
Предприятия,
фирмы, корпорации часто используют
свои стандарты на электронный обмен
данными. В этих случаях Программное
Обеспечение (ПО) EDI осуществляет
преобразование фирменных форматов
и синтаксис в стандартные и, наоборот,
стандартные в фирменные. Ядром такого
программного обеспечения является
Электронная
Таблица (ЭТ). Она отображает
фирменные деловые документы в
стандартные наборы
трансакций.
Первоначально
EDI использовалась в территориальных
сетях. Теперь же эта технология
применяется и в локальных
сетях Из технологии обработки
заказов EDI превратилась в комплексный
универсальный элемент управления
бизнесом. На основе EDI создаются даже
автоматизированные электронные
биржи.
Сетевая
служба FTAM. Сетевая
служба FTAM - сетевая
служба, обеспечивающая управление
файлами
и доступ
к ним. FTAM
расположена на прикладном
уровне, определена Международной
Организацией Стандартов (МОС) и
опирается на базовую
эталонную модель взаимодействия
открытых систем.
Располагается
FTAM на верхнем подуровне прикладного
уровня. FTAM обеспечивает взаимодействие
в информационной
сети разнотипных абонентских
систем, которые имеют различные
виды файлов, их форматы
и состав операций с ними. Протокол
FTAM основан на модели
виртуальной
Базы
Данных (БД), определяемой стандартными
процедурами и характеристиками.
FTAM
предназначена для организации
взаимодействия прикладных
процессов, один из которых управляет
базой данных, а другой работает с ее
файлами. Первый процесс пассивен и
отвечает на запросы второго. Второй
же активен и является инициатором
взаимодействия. В течении этого
взаимодействия второй процесс
получает доступ к файлам и осуществляет
нужные действия над ними. Используемые
во FTAM файлы являются стандартными.
В каждой базе данных хранятся атрибуты
и содержимое файлов, а также атрибуты
режимов работы с файлами. Например,
пароль
доступа, метод обработки, форма
управления соперничеством
пользователей.
Пользователю
виртуального файлохранилища FTAM
предоставляет четыре вида сервиса:
создание
ассоциации взаимодействующих
прикладных процессов;
поиск
и выбор файла;
доступ
к содержимому файла;
пересылка
файла из одной системы в другую.
Сетевая
служба JTM. Сетевая
служба JTM — сетевая
служба передачи заданий
и управления их выполнением. JTM
работает в соответствии со стандартами
ISO и оперирует с так называемыми
виртуальными
заданиями. Виртуальные задания,
т.е. задания, удовлетворяющие принятыми
в JTM требованиям, выполняются во
всех, работающих со службой абонентских
системах. В этом смысле служба
выступает в роли компонента Сетевой
Операционной Системы (СОС),
выполняющего задания пользователей.
При
работе с заданиями могут происходить
различные отказы:
прекращение взаимодействия,
перегрузки, тупиковые
ситуации. Служба следит за
выполняемой работой и ликвидирует
возникающие отказы. Эти действия
осуществляются специальной подслужбой,
называемой "Целостность,
одновременность, восстановление"
CCR.
Подслужба CCR разработана не специально
для JTM и используется в других службах,
определяемых стандартами ISO. CCR
начинает цикл действий, контролирует
ход его выполнения, завершает работу
либо возвращается, в случае отказа,
к исходной точке.
Выполняемое
задание делится на части. Задание
может ветвиться и распространяться
по информационной
сети. Благодаря этому, JTM обеспечивает
выполнение в сети любых прикладных
процессов. Задания, в случае
необходимости, могут передаваться
из одной абонентской системы в
другую. Для этого программы
и файлы,
необходимые для работы, должны
находиться в выделенных для этой
цели системах. Данные,
полученные в результате выполнения
задания, направляются в указанную
пользователем абонентскую систему.
Сетевая
служба JTM располагается в прикладной
платформе на верхнем подуровне
прикладного
уровня.
Сетевая
служба MHS/MOTIS. Сетевая
служба MHS/MOTIS — сетевая
служба, обеспечивающая работу
электронной
почты. Задачей Системы управления
сообщениями MHS,
определенной стандартом
ITU-T,
является хранение, копирование,
передача и выдача адресатам самых
разнообразных сообщений.
При этом пользователь
имеет возможность не только формировать
и отправлять по необходимому ему
адресу
сообщение, но также выбирать вариант
его доставки, устанавливать уровень
защиты
данных. О доставке сообщения
пользователь получает подтверждение.
Благодаря гибкой структуре MHS/MOTIS
может размещаться в одной либо группе
абонентских
систем.
Важнейшими
характеристиками сетевой службы
являются межпользовательский обмен
сообщениями, который, строго говоря,
осуществляется не между системами,
а между конкретными пользователями.
Роль пользователей могут выполнять
не только определенные лица, но и
прикладные
программы, находящиеся в системах,
работающих с сетевой службой.
MHS/MOTIS
выполняет для пользователей различные
виды сервиса:
редактирование
сообщений;
передача
сообщений одному либо группе
адресатов;
вручение
адресату сообщения в заранее
указанное отправителем время;
регистрация
времени
представления отправителем и
получения адресатом сообщения;
оповещение
отправителя о доставке либо
невозможности доставки сообщения;
создание
копий сообщения;
обеспечение
секретности содержимого сообщения;
информация
об изменении адресов,
о появлении новых абонентов;
ведение
справочника пользователей (абонентов),
их почтовых
ящиков.
Непосредственно
с электронной почтой связана сетевая
служба DS* и служба электронного
перевода денег EFT.
Она предоставляет справочную
информацию о пользователях службы
MHS/MOTIS.
Сетевая
служба NMS. Сетевая
служба NMS — сетевая
служба, выполняющая процессы
управления
сетью. NMS
разработана Международной
Организацией Стандартов (МОС) и
располагается на прикладном
уровне. Обеспечивая управление
информационной
сетью, эта служба определяет:
функции
управления;
виды
сервиса,
предоставляемые для управления;
структуру
управляющей информации
(термины и категории);
протоколы,
определяющие транспортировку
управляющей информации.
Основная
работа, связанная с управлением
сетью, осуществляется Объектами
административного управления (ОАУ),
расположенными на всех уровнях
области Взаимодействия
Открытых Систем (ВОС).
Каждый
уровень осуществляет собственное
управление. Для этого объект
административного управления
получает всю необходимую ему
информацию о работе своего уровня.
Она содержит сведения о функционировании
протоколов уровня, передаче сообщений,
появляющихся ошибках, изменениях
состояний, потоках данных.
Объект административного управления
осуществляет загрузку программ
уровня, управляёт изменением
протокольных параметров и ресурсов.
NMS требует предоставления информации
о работе всех уровней. Поэтому в
системе создается группа взаимосвязанных
Баз
Данных (БД), состоящая из основной
базы и баз (Б), находящихся на всех
уровнях. Последние собирают сведения
о работе уровней.
Прикладной
сервисный объект системного управления
SMASE
является функциональным
блоком, обеспечивающим обработку
сведений, необходимых для работы
управляющих прикладных
процессов. Для этого прикладные
объекты
системного управления, расположенные
во всех системах
сети, обмениваются друг с другом
необходимыми сообщениями. Эти объекты
располагаются на верхнем подуровне
(7Б) прикладного уровня и работают
совместно с Сервисными объектами
общей управляющей информации CMISE
и Протоколом общей управляющей
информации CMIP.
NMS
обеспечивает работу Управляющих
прикладных процессов, которые
получают сведения от Прикладного
сервисного объекта системного
управления SMASE
и Объектов Административного
Управления (ОАУ) всех уровней системы.
Управляющие прикладные процессы
выполняют пять функций: определение
неисправностей и ликвидация ошибок,
поддержание высокой производительности,
обеспечение безопасности
данных, управление конфигурацией
сети, учет работы сети и составление
отчетов.
NMS
обеспечивает управление не только
сетью, но и входящими в нее системами.
Для этого выполняются функции:
формирование
и модификация логической структуры
систем, включая удаленную загрузку
программ и установление изменяемых
параметров;
контроль
за работой систем;
сбор,
обработка и регистрация сообщений
о происходящих ошибках;
анализ
и локализация неисправностей;
подключение
при неисправностях альтернативных
компонентов сети: каналов,
процессоров,...;
регистрация
сведений, характеризующих работу
систем;
передача
сведений персоналу сети.
Сетевая
служба NMS может быть предназначена
не только для управления одной сетью,
но и обеспечения интегрального
сетевого управления смешанными
сетями. Служба располагается в
административной
системе, предназначенной для
управления сетью. Агенты управления
находятся во всех абонентских
системах.
Сетевая
служба ODA. Сетевая
служба ODA — сетевая
служба, обеспечивающая обработку
и передачу документов.
ODA
располагается на прикладном
уровне и определяет обмен документами
(письмами, служебными записками,
отчетами), которые могут содержать
тексты,
таблицы,
изображения,
речь.
Документы могут редактироваться и
их формат
изменяться.
Архитектура
документа определяет:
взаимоотношение
различных видов данных;
информационную
структуру документа (редактирование,
форматирование, размещение в файле,
ключевые слова, расположение
столбцом);
взаимосвязь
документов: их группировка в
зависимости от темы, адреса
отправления либо назначения и т.д.
Содержание
документа может быть представлено
в следующих формах:
символьный
текст;
растровые
изображения;
диаграммы
(геометрическая графика);
вычисляемые
таблицы;
звук
(речевые аннотации).
Распределение
документов включает:
кодирование
документов и их частей;
синтаксис
передачи документов;
методика
передачи частей документов (например,
только данных, необходимых для
заполнения таблицы);
удаленный
интерактивный
доступ
к документам.
Сетевая
служба ODA достаточно сложна. Поэтому
в ней определяются подмножества,
именуемые прикладными профилями
документов. Важное значение для ODA
имеют цветное изображение документов
и их аудио-содержание (речевые
аннотации). Новые возможности
предоставляет динамическая графика,
которая обеспечивает создание и
обработку видеофильмов.
В
прикладной
платформе сетевая служба ODA
расположена на верхнем подуровне
прикладного уровня.
Сетевая
служба VT. Сетевая
служба VT - сетевая
служба, обеспечивающая стандартные
формы работы терминалов
в информационной
сети. Сетевая служба VT,
определяемая стандартами
ISO,
располагается на прикладном
уровне и заменяет собой большое
множество программ
эмуляции
многочисленных терминалов, выпускаемых
различными производителями.
В
службе используется понятие
виртуального
терминала.
В
соответствии с этим, реальные
терминалы, используемые в информационной
сети, должны быть отображены в
виртуальный терминал. Естественно,
что реальные терминалы имеют различные
характеристики - экран,
клавиатуру,
набор
и последовательность команд.
Поэтому в абонентской
системе должен быть функциональный
блок, преобразующий эти характеристики
в те, которые приняты в сетевой службе
VT.
РЕАЛИЗАЦИЯ
УПРАВЛЕНИЯ В МОДЕЛИ ВОС
Управление
в рамках семиуровневой модели
взаимосвязи открытых систем ВОС
можно рассматривать как взаимодействие
между объектами с помощью
коммуникационных
протоколов для
обеспечения функций и услуг управления.
Объектом управления является
информация управления, которой
обмениваются взаимосвязанные
открытые системы. Стандарты ISO
определяют коммуникационные
протоколы, необходимые для успешного
обмена информацией управления между
программами прикладного уровня.
Соответствующий стандарт ISO 9595
содержит описание услуг управления
с помощью элемента
общей услуги информации управления
(Common Management Information Services Element, CMISE). В
рамках объектно-ориентированного
подхода элемент
CMISE
рассматривается как элемент
услуги
приложения
(application service element, ASE), разработанный
для поддержки управления системами.
Элемент
услуги приложения ASE – это логический
объект, который обеспечивает
взаимодействие между различными
приложениями управления. Предметом
управления ASE может являться контроль
взаимодействия между элементами
услуги управления. К услугам ASE
относится управление передачей
файлов, управление доступом, удаленное
управление директориями. При
реализации ASE предусматривается
возможность многократного использования
этого элемента несколькими приложениями
управления.
Определение
CMISE осуществляется в терминах услуг
или сервисов, которые обеспечиваются
пользователю с помощью т.н. машины
протоколов
(protocol machine). Машина протоколов позволяет
формировать блоки
данных протокола PDU.
Услуги управления информацией
используются приложениями управления
для обмена информацией и необходимыми
командами. Существуют следующие
услуги управления ВОС:
1.
Услуги
управления ассоциацией
(management association services, MAS) − это услуги,
которые обеспечивают организацию
обмена информацией между управляемым
объектом и управляющим объектом.
2.
Услуга
передачи уведомлений в процессе
управления
(management notification service, MNS) − это одиночный
сервисный элемент, который используется,
чтобы передать прикладной программе
уведомление/подтверждение о получении
информации по управлению.
3.Услугиуправленияоперациями
(management operation services, MOS) состоят из шести
операций, с помощью которых оказываются
услуги по передаче и обработке
информации:
•
получение
информации об управляемом объекте;
•установка
значения атрибута (параметра);
•генерация
сообщения о сетевом событии;
•получения
информации об управляемом объекте.
Услуги
управления в процессе взаимодействия
с пользователями (приложениями
управления) показаны на рисунке.
Услуга
общей информации управления,
использующая CMISE, предоставляет
дополнительные возможности по
структурированию информации
управления.
Протокол
CMIP используется для обеспечения
взаимодействия между менеджерами
и агентами.
Рисунок.
Взаимодействие между приложениями
управления и CMISE
Элементы,
формирующие структуру управления
ВОС и относящиеся к ASE, следующие:
•Элемент
услуги
управления
системой
(system management application service element, SMASE).
•Элемент
услуги
общей
информации
управления
(common management information service element, CMISE).
•Элемент
услуги
управления
ассоциацией
(association control service element, ACSE).
•Элемент
услуги
удаленного
выполнения
операции
(remote operations service element, ROSE).
•Функция
координации
(co-ordination function).
Взаимодействие
между элементами структуры управления
реализуется с помощью прикладного
программного
интерфейса
(application program interface, API).
Элемент
SMASE при физической реализации
представляет собой программное
приложение или аппаратно-программный
комплекс, который в автоматическом
режиме или с помощью оператора
инициирует выполнение той или иной
операции управления.
Элемент
ACSE используется, чтобы установить
ассоциативные
связи
или
ассоциации
(application associations) между программой-менеджером
и программой-агентом. Приложения
управления должны поддерживать
правила, которые необходимы для
координации обмена информацией
между ASE. Эти правила записываются
с помощью параметров услуг пользователя
ASCE.
Всего
в CMISE имеются два вида средств
управления системами, удовлетворяющих
стандартам ВОС. Это общие
услуги информации управления
(сommon management information services, CMIS) и общий
протокол информации управления
(common management information protocol, CMIP).
Элемент
ROSE используется для оформления
информационных запросов и их передачи
с помощью механизма удаленного
вызова
процедур
(remote
procedure calls, RPC) используемого в разных
системах. В рамках международных
стандартов, как правило, рассматриваются
элементы и услуги модели ВОС, имеющие
отношение к обмену информацией
управления, а внутренняя логика
процесса управления не затрагивается.
Рисунок.
Элементы услуги в модели управления
ВОС
Услуги
CMIS определяют функции для контроля
и управления сетью, обеспечивают
интерфейс пользователя услуг
управления. Протокол CMIP используется
для поддержки обмена информацией
управления между открытыми системами,
обеспечивает взаимодействие открытых
систем на прикладном уровне ВОС.
CMIS и CMIP являются частью большого
набора стандартов для управления
системами на основе модели ВОС.
CMIS
определяет услуги, которые могут
поддерживать программы-менеджеры
и программы-агенты, а когда менеджер
и агент устанавливают связь друг с
другом, они «договариваются» о том,
какие услуги будут использоваться
при взаимодействии.
Протокол
обмена информацией CMIP основан на
принципе ответа на запрос, где
менеджер с помощью запроса инициирует
операции управления на одном или
большем количестве управляемых
объектов.
Описываемая
архитектура требует, чтобы была
чётко определена логическая и
информационная структура управляемого
объекта. В данном случае управляемый
объект является абстрактным
представлением управляемого
физического ресурса и содержит
информацию управления, требуемую
для успешного осуществления процесса
управления. При каждом информационном
обмене программа−менеджер посылает
программе−агенту запрос на выполнение
операции управления с помощью
протокола CMIP.
Рисунок.Управление
открытыми системами в рамках модели
«менеджер-агент»
Операции
управления подразумевают наличие
протокола информационного обмена
для создания, удаления, чтения данных
и изменения информации управления.
Протокол
CMIP поддерживает доступ к базам данных
управления MIB. Управляемые объекты
на уровне базы данных имеют имена,
им присваиваются атрибуты, описывается
режим работы объектов. Данные об
управляемых объектах могут быть
созданы, удалены, модифицированы.
Сведения
MIB позволяют прикладной программе
управления осуществлять действия
над объектами, которые инициированы
сетевым менеджером. Описание поведения
объекта в MIB обусловлено ресурсом
управления, который этот объект
представляет.
Тип
услуги или сервиса CMISE определяет
набор элементарных операций или
примитивов,
с помощью которых пользователь услуг
CMIS получает доступ к услугам
управления.
В
CMIS существует механизм выдачи
подтверждений о выполнении команды
request. Некоторые услуги CMIS поддерживают
операции, выполнение которых не
требует специального подтверждения.
Кроме примитива request
существуют следующие примитивы:
•indication
[индикация] − свидетельствует о
наступлении какого−то события,
например поступление запроса request;
•response
[ответ, отклик] − ответная реакция
на событие, например выполнение
запроса;
•confirmation
[подтверждение] − сообщение о
поступлении ответа на направленный
запрос.
Услуги
с подтверждением требуют, чтобы
агент, который выполняет операции
на управляемом объекте, послал с
помощью CMIS управляющей системе
«квитанцию»
о
приёме
или ответ
(receipt, responce) со сведениями о том,
осуществлялась ли требуемая операция
управления успешно или произошла
ошибка. При услугах без подтверждения
такой механизм отсутствует.
ОБЩИЙ
ПРОТОКОЛ ИНФОРМАЦИИ УПРАВЛЕНИЯ CMIР
Этот
протокол позволяет осуществлять
управление элементами всех уровней
модели ВОС формирует блоки данных
протокола PDU и осуществляет обмен
ими между одноуровневыми приложениями
управления. Протокол CMIP используется
для обеспечения услуг управления
операциями и услуг передачи уведомлений
CMISE. В совокупности протоколы CMISE,
ASCE и ROSE представляют собой стек
протокола CMIP. Каждая услуга CMISE
определяется с помощью нескольких
CMIS-примитивов, которые отображаются
в виде соответствующих PDU.
Важное
значение в понимании функционирования
протокола CMIP имеет понятие протокольной
машины CMIP (common
management information protocol machine, CMIPM), которая
является логическим представление
основных функций этого протокола.
На стороне менеджера, который выдаёт
управляющие команды, протокольная
машина принимает запросы пользователя
CMIS на предоставление услуг управления.
На основании запросов в CMIPM
инициализируются те или иные
примитивы. В результате CMIPM выдаёт
ответы (подтверждения) на запросы
услуг, а также генерирует блоки
данных CMIP PDU, которые передаются на
нижестоящий уровень ROSE для осуществления
операций, необходимых пользователю
услуг CMISE.
На
стороне агента машина CMIPM принимает
с нижестоящих уровней корректные
блоки PDU и передаёт информацию о
требуемых услугах управления на
уровень CMISE. Если блок PDU не корректен,
то он отбрасывается, о чём выдаётся
уведомление в сторону менеджера.
Важно,
что машина CMIPM осуществляет обработку
блоков PDU, не затрагивая вопроса о
том, что происходит с данными на
уровне CMIS.
Система
с подтверждением должна использовать
по крайней мере одну из возможных
услуг. При этом система может выполнять
функции как управляемой системы так
и управляющей. В данный момент времени
система либо сама является управляющей,
либо управляется другой системой.
Далее рассмотрим некоторые услуги,
доступные с помощью CMIP.
Рисунок.
Структура протокольной машины CMIPM
В
процессе обмена информацией
используется услуга A-ASSOCIATE и
соответствующие примитивы для
установления взаимодействия между
двумя приложениями.
Услуга
A-RELEASE используется, когда пользователь,
пославший запрос, не согласен с ранее
организованным взаимодействием
между приложениями. При этом в случае
прекращения ранее установленной
связи между приложениями не происходит
потери информации.
Таблица
1. –Услуги ROSE
Услуга
A-ABORT используется в случае возникновения
ошибок при передаче информации или
при аварии (существует потенциальная
возможность потери информации).
Услуга A-ABORT используется в случае,
когда обнаружено нарушение
коммуникационного протокола или
когда сеанс связи между приложениями
еще не установлена.
Услуга
A-P-ABORT используется для обнаружения
аварийного прекращения операции на
уровне представления с возможной
потерей информации при обмене
информацией.
Каждой
услуге соответствует свой примитив
запроса на предоставление данной
услуги. В качестве примера
функционирование CMIS и ROSE с помощью
протокола CMIP рассмотрим услугу
установления IP-адреса удалённого
компьютерного устройства с помощью
услуги и соответствующей ей процедуры
Get.
Услуга
– аварийное прекращение операции
Установление
связи менеджера и агента
Установление
взаимодействия между приложениями
Отсутствие
согласия или наличие ошибок при
передаче
Запрос
программы о передаче запрошенной
операции
Рисунок.
Стек протокола CMIP: ACSE и ROSE
Процесс
обмена примитивами и соответствующими
им блоками PDU при выполнении
рассматриваемой процедуры приведён
на рисунке. Здесь показано, как
система управления (инициатор
запроса) SMISE выполняет процедуру
M-Get. Обработка примитива M-GET1 request на
CMIPM приводит к инициализации машины
протокола CMIP для формирования
соответствующего APDU.
Запрос
на оказание услуги M-GET с помощью CMIP
передаётся на удалённый объект
(получателю запроса) через ROSE. После
получения M−GET request, протокольная
машина CMIPM инициатора запроса
осуществит следующие операции:
•Протокольная
машина cформирует блок PDU протокола
CMIP, который обозначается APDU, для
инициализации (т.е. выполнения)
операции M−GET у получателя запроса.
•Машина
CMIPM инициатора запроса передаст
сформированный APDU получателю запроса
с помощью услуг ROSE с использованием.
Блок
APDU будет передан через 1−6 уровни
модели ВОС. Протокольная машина
CMIPM получателя запроса в случае, если
полученный блок APDU корректен, выдаёт
в сторону получателя примитив
индикации M−GET (M-GET indication), который
указывает на появление запроса
M−GET. Если поступивший от инициатора
запроса PDU некорректен, то CMIPM на
приёме сформирует PDU с уведомлением
об ошибке и направит этот PDU через
ROSE в сторону инициатора запроса с
помощью процедуры RO-REJECT-U – результат
запроса.
Результат
запроса
Запрос
программы
Запрос
программы
Результат
запроса
Рисунок.
Процедура обмен блоками PDU
При
формировании ответа на M−GET,
протокольная машина получателя
запроса осуществит следующие операции
:
•Примет
ответ от получателя запроса –
пользователя услуг CMISE – в виде
примитива M-GET responce. Запрашиваемый
IP-адрес устройства содержится в поле
данных примитива.
•Сформирует
блок данных протокола APDU, подтверждающий
выполнение операции M−GET.
•Передаст
сформированный APDU с искомым IP-адресом
в сторону инициатора запроса с
помощью процедуры; результат в случае
ошибки ответ передаётся с помощью
процедуры RO−ERROR – ошибка.
При
получении PDU от получателя запроса,
протокольная машина CMIPM инициатора
запроса выполнит следующие операции
:
•В
случае, если полученный APDU с искомым
IP-адресом корректен, выдаёт в сторону
инициатора запроса примитив индикации
RO-RESULT (RO-RESULT indication) – результат;
•Выдаст
уведомление (подтверждение) о
выполнении запроса в виде примитива
M−GET confirmation и требуемые данные об
IP-адресе в сторону инициатора запроса.
•Для
некорректного APDU сформирует
специальный блок данных протокола,
содержащий сообщение об ошибке; этот
блок данных будет передан в сторону
получателя запроса.
Таким
образом, протокол CMIP осуществляет
передачу информации управления
между различными открытыми системами,
обеспечивая взаимосвязь и управляемость
этих систем.
МОДЕЛЬ
УПРАВЛЕНИЯ, ИСПОЛЬЗУЕМАЯ В ПРОТОКОЛЕ
SNMP
При
использовании протокола SNMP программа
пользователя (менеджер сети)
осуществляет виртуальные соединения
с SNMP-агентами. Программа SNMP-агента
установлена на элементе сети, и
предоставляет менеджеру сети
информацию о состоянии данного
элемента. Этот процесс осуществляется
в рамках системы
управления сетью
(network management systems, NMS).
Управляемое
устройство, на котором функционирует
программа-агент, может быть любым –
сервер доступа в Интернет, УПАТС,
принтер, маршрутизатор, концентратор
ЛВС и т.п. В данной ситуации программы
управления должны быть построены
таким образом, чтобы минимизировать
воздействие программы-агента на
управляемое устройство.
Рисунок.
Использование протокола SNMPv2
Агенты
по заданию менеджера или автоматически
(по расписанию) могут отслеживать
следующие показатели работы
оборудования:
•Число
и состояние виртуальных каналов;
•Число
определенных видов сообщений о
неисправностях/отказах
•Число
входящих и исходящих пакетов для
данного устройства;
•Максимальная
длина очереди на входе/выходе;
•Отправленные
и принятые широковещательные
сообщения;
•Отказавшие
и вновь запущенные в эксплуатациюсетевые
и абонентские интерфейсы.
Стандартная
IMIB протокола SNMP включает различные
объекты/элементы, создаваемые с
целью измерения, мониторинга и
контроля функционирования протоколов
IP,TCP,UDP, контроля IP-маршрутов,
TCP-соединений, состояния сетевых
интерфейсов элементов сети в целом.
При управлении протокол SNMP обращается
за информацией именно к IMIB.
Существует
два стандарта IMIB, применяемых в SNMP,
MIB-I и MIB-II. Существует версия MIB для
удалённого управления с помощью
агентов протокола
удалённого
мониторинга
сетей
(Remote Monitoring, RMON).
В
стандарте MIB-I определены только
операции чтения из базы. В этой версии
существует всего 114 управляемых
объектов, разделённые на 8 групп.
Команды
управления в SNMP используются в первую
очередь для получения текущего
значения или установки нового
значения атрибута объекта управления
с соответствующим идентификатором.
В
тоже время существует возможность
с помощью добавления в IMIB новых
элементов – таблиц, столбцов в
существующую таблицу – расширять
описания существующих или создавать
новые управляемые объекты.
ЭЛЕМЕНТЫ
ПРОТОКОЛА
SNMP
В
протоколе SNMP можно выделить следующие
основные стандартизованные элементы.
1.Стандартный
формат
сообщения
(standard message format), который определяется
форматом сообщения UDP.
2.Стандартный
набор управляемых объектов
(standard set of managed objects) представляет
собой набор стандартных объектов и
значений (values) их атрибутов в IMIB. Эти
значения можно получить в ответ на
запросы станции управления.
3.Стандартный
способ добавления объектов
(standard way of adding objects). Этот метод позволяет
фирмам-производителям расширять
стандартный набор управляемых
объектов посредством спецификации
новых управляемых объектов и
добавления их в IMIB.
Начиная
с протокола SNMP версии 1 (SNMPv1) были
определены четыре типа стандартных
SNMP-операций для управления объектами:
•Операция
Get
[получить] применяется чтобы возвратить
(получить) значение атрибутов
управляемого объекта из группы IMIB.
•Операция
GetNext
[получить следующий] существует,
чтобы возвратить имя (и значение
атрибутов) следующего по порядку
управляемого объекта в IMIB.
•Операция
Set
[установить] применяется, чтобы
установить на управляемых объектах
значения атрибутов (изменить
содержание ячейки таблицы.
•Операция
Trap [прерывание]
используется сетевыми устройствами
асинхронно; с помощью прерывания,
остановив выполнение других программ
управления, элементы сети могут
самостоятельно, без специального
запроса, сообщить менеджеру сети о
возникших отказах, перегрузках и
т.п.
В
протоколе SNMP версии 2 (SNMPv2) помимо
перечисленных, были добавлены новые
SNMP-операции, а именно:
•Операция
GetBulk
[получить перечень] используется
для извлечения большого числа
значений из таблиц, а не единичных
значений атрибутов.
•Операция
Inform
[информировать] позволяет одной NMS
выполнять операцию Trap на другой NMS
и, соответственно, получать ответ
на асинхронный запрос.
•Операция
Report
[рапорт] позволяет агенту сообщить
о состоянии управляемого ресурса;
сообщение выдаётся без запроса.
Каждой
перечисленной операции соответствует
блок PDU определённого формата.
Используя перечисленные операции
(команды) можно сформировать
соответствующие примитивы запросов
для обмена между менеджером и агентом.
В
результате выполнения операции
менеджером или агентом будет
сгенерирован один из следующих
запросов:
•Запрос
«Получить»
(GetRequest) – используется чтобы определить
технические характеристики и
состояние устройства с помощью
операции Get.
•Запрос
«Получить
следующий»
(GetNextRequest) –используется сетевыми
менеджерами для «просмотра» всех
имен управляемых объектов и их
атрибутов, которые поддерживаются
агентом на данном сетевом устройстве.
Эта процедура выполняется начиная
с первого объекта так, чтобы после
выборки информации о первом объекте
перейти к выборке данных по следующему
объекту в IMIB (c использованием
GetNext).
Данная процедура может повторяться
до тех пор, не будет обнаружена ошибка
сетевого устройства или до конца
перечня объектов IMIB.
•Запрос
«Установить»
(SetRequest) – позволяет осуществлять
действия, связанные с изменением
значения атрибута с помощью операции
«Set».
•Запрос
«Прерывание»
(Trap). Протокол SNMP предоставляет
механизм, посредством которого
сетевые устройства могут «выдавать
наружу» (reach out) или самим себе (через
Trap) прерывание, обозначающее наличие
проблемы.
Кроме
перечисленных, имеются запросы типа
InformRequest [информировать] и GetBulkRequest
[получить перечень]. Сообщение
Response [ответ] включает информацию,
передаваемую в ответ на запрос.
Рисунок
Обмен запросами и ответами в SNMP v2
Таблица
. Назначение полей PDU протокола SNMP
Все
вышеупомянутые типы операций и
запросов закодированы в виде PDU,
которыми обмениваются устройства,
поддерживающие протокол SNMP.
Рисунок.
Форматы блоков PDU в SNMP (v1 и v2)
ФУНКЦИИ
УПРАВЛЕНИЯ
SNMP
Самый
убедительный довод в пользу применения
протокола SNMP заключается в том, что
он разрабатывался как протокол,
поддерживающий единый способ доступа
к сетевому устройству на основе
стека протоколов TCP/IP. Поскольку стек
протоколов TCP/IP достаточно универсален,
следовательно универсален и протокол
SNMP.
Дополнительный
аргумент в пользу применения SNMP
состоит в том, что данный протокол
определяет состояние устройства
без организации сложного удаленного
доступа или без потребности в сложных
процедурах аутентификации. В
результате появляется возможность
получения большого числа данных о
состоянии элементов крупномасштабной
сети. Однако отсутствие надёжных
средств обеспечения информационной
безопасности нецелесообразно с
точки зрения живучести и надёжности
системы управления. Поэтому в версии
3 протокола SNMP аутентификации и
криптозащите уделено особое внимание.
Большинство
программ-менеджеров в SNMP обеспечивают
следующие функции управления:
-
Функции сбора информации о
неисправностях
(alarm polling functions). SNMP-менеджеры обеспечивают
возможность установить пороги
чувствительности
(thresholds) на управляемых объектах
(максимально допустимое число
ошибок), и своевременно выдавать
аварийное сообщение, когда эти пороги
превышены. Реализация данной функции
позволяет постоянно контролировать
техническую исправность сети и её
отдельных элементов.
-
Функции
контроля
тренда
(trend monitoring functions). Периодически
производится считывание значений
атрибутов, что позволяет оценить
рабочие характеристики сети в
динамике т.е. построить тренд сети
по тому или иному признаку. В частности,
описанная функция может использоваться
для определения графика (профиля)
нагрузки сети на заданном интервале
времени.
-
Функции
прерывания
при
приеме
(trap reception functions). SNMP-менеджеры
обеспечивают возможность приёма и
фильтрации SNMP-прерываний, которые
выдаются сетевыми устройствами.
Прерывания позволяют сетевым
устройствам самостоятельно, не
дожидаясь запроса, сообщать о
проблемах, отказах и т.п.
Протокол
SNMP версии 3 имеет следующие особенности:
•Модульность
архитектуры как программных решений,
так и спецификаций SNMPv3. Модульность
позволяет сочетать в рамках одной
системы управления NMS компоненты от
разных поставщиков, проводить
модернизацию протокола и развивать
его.
•Поддержка
режима распределённой обработки
данных.
•Возможность
работать в режиме агента, менеджера
или в совмещённом режиме.
•Поддержание
конфигурации сети любого масштаба
и состава.
•Механизмы
обеспечения информационной
безопасности для защиты сообщений
и разграничения доступа к информации
управления.
На
рисунке представлены основные
компоненты архитектуры SNMPv3 для
конфигурации агента и менеджера.
Основных
компонентов два:
•машина
протокола SNMP, SNMP-машина (SNMP engine);
•приложения
управления
SNMP (SNMP application).
Машина
протокола SNMP присутствует во всех
управляемых и управляющих системах
т.е. и в менеджерах и в агентах. Машина
протокола SNMP осуществляет функции
посылки и приёма блоков PDU, функции
аутентификации, шифрование и
дешифрование SNMP-сообщений, функции
контроля доступа к управляемым
объектам.
Машина
протокола SNMP по отношению к приложению
управления функционирует в режиме
приёма и в режиме передачи. Машина
протокола SNMP имеет модульную структуру
и включает четыре компонента:
•диспетчер
(dispatcher);
•подсистема
обработки
сообщений
(message processing system);
•подсистема
информационной
безопасности
(security subsystem);
•подсистема
разграничения
доступа
(access control subsystem).
Рисунок.
Конфигурации менеджера и агента в
SNMP v3
Диспетчер
занимается приемом и отправкой
SNMP-сообщений. Диспетчер выполняет
функции управления нагрузкой.
Диспетчер по номеру версии в заголовке
PDU определяет, какой тип обработки
сообщений необходим для данного
SNMP-сообщения.
Подсистема
обработки сообщений принимает/передаёт
сообщения диспетчеру. На передаче
данная подсистема добавляет
необходимый заголовок для передачи
через сеть передачи данных; на приёме
эта подсистема извлекает PDU протокола
SNMP из пакета, полученного по сети
передачи данных.
Подсистема
информационной безопасности (security
subsystem) протокола SNMP обеспечивает
функции аутентификации и шифрования.
В протоколах SNMPv1 и SNMPv2 особого
внимания вопросам информационной
безопасности управления не уделялось.
SNMPv3 включает модель обеспечения
безопасности, которая предусматривает
меры защиты против следующих
потенциальных угроз:
•модификация
информации управления при передаче;
•подмена
данных, как средство неавторизованного
выполнения операций управления на
объекте;
•резкое
увеличение потока сообщений до
уровня, превышающего обычные
отклонения;
•несанкционированное
ознакомление с сообщениями.
При
передаче подсистема безопасности
получает SNMP-сообщение от подсистемы
обработки сообщений. В зависимости
от требуемой услуги управления,
подсистема безопасности может
шифровать PDU и часть полей в заголовке
сообщения SNMP.
Защищённое
сообщение возвращается в подсистему
обработки сообщений. На приёме
происходит обработка сообщения в
обратном порядке (дешифровка), однако
дополнительно может выполняться
проверка.
Протокол
SNMPv3 не предусматривает специальных
средств защиты против атак на
доступность.
Модель
безопасности включает подсистему
разграничения доступа к информации.
Подсистема обеспечивает услуги
авторизации для контроля доступа к
IMIB в случае чтения или установки
новых атрибутов объектов.
Модель
доступа описана в документе RFC 2275.
Согласно данной рекомендации, каждый
субъект управления получает т.н.
представление
(view)
о данных системы, а также о подмножестве
информации управления, задаваемой
спецификациями IMIB. Это позволяет
сделать доступными только те функции,
которые включены в представление.
Для
операций чтения, записи и выдачи
уведомлений могут использоваться
отдельные представления, что повышает
надёжность механизма информационной
защиты SNMPv3.
В
SNMPv3 предусмотрено пять стандартных
модулей приложений управления:
•Генерация
команд (command generator applications) – осуществляет
мониторинг и манипуляции с данными
управления на удалённых агентах.
Использует стандартные PDU из таблицы
2.2.
•Прием
уведомлений (notification receiver application) –
обрабатывает входящие асинхронные
сообщения типа Trap, Response.
•Создание
извещений (notification originator application) –
инициирует асинхронные сообщения.
Использует запросы InformRequest.
•Доверенное
перенаправление (proxy forwarded applications) –
использует возможности диспетчера
для перенаправления сообщений SNMP.
Формат
сообщения SNMP v3 изменяется
Рисунок.
Формат сообщения SNMP
v3
Таблица.
Назначение полей PDU протокола SNMP v3
СРАВНИТЕЛЬНАЯ
ХАРАКТЕРИСТИКА ПРОТОКОЛОВ УПРАВЛЕНИЯ
SNMP И CMIP
• Применение
протокола SNMP позволяет строить как
простые, так и сложные системы
управления, а применение протокола
CMIP определяет некоторый, достаточно
высокий начальный уровень сложности
системы управления, так как для его
работы необходимо реализовать ряд
вспомогательных служб, объектов и
баз данных объектов.
• Уведомления
(traps) агента SNMP посылаются менеджеру
без ожидания подтверждения, что
может привести к тому, что важные
сетевые проблемы останутся
незамеченными, так как соответствующее
уведомление окажется потерянным, в
то время как уведомления агента CMIP
всегда передаются с помощью надежного
транспортного протокола и в случае
потери будут переданы повторно.
• Решение
части проблем SNMP может быть достигнуто
за счет применения более интеллектуальных
MIB (к которым относится RMON MIB), но для
многих устройств и ситуаций таких
MIB нет (или нет стандарта, нет
соответствующей MIB в управляемом
оборудовании).
• Протокол
CMIP рассчитан на интеллектуальных
агентов, которые могут по одной
простой команде от менеджера выполнить
сложную последовательность действий.
• Операции,
которые выполняет агент SNMP, примитивны.
Это приводит к многочисленным обменам
между менеджером и агентом. А так,
как протокол SNMP в качестве транспортного
протокола использует UDP, который не
поддерживает подтверждения о доставке
информации, важные данные могут быть
потеряны, а сообщения CMIP всегда
доставляются адресату с подтверждением.
• Протокол
CMIP существенно лучше масштабируется,
так как может воздействовать сразу
на несколько объектов, а ответы от
агентов проходят через фильтры,
которые ограничивают передачу
управляющей информации только
определенным агентам и менеджерам.
• Управляемый
объект в CMIP и модели ВОС — это
законченное описание управляемого
ресурса; в SNMP объектом может быть и
атрибут.
• Существуют
некоторые отличия понятия «управляемый
объект» в протоколах CMIP и SNMP.
Управляемый объект в протоколе CMIP
− это законченное и подробное
описание управляемого ресурса;
управляемым объектом в протоколе
SNMP является чаще всего некоторый
атрибут объекта, например число
отказов или сбоев.
В
таблице приведена сравнительная
характеристика протоколов SNMP и CMIP.
|
SNMP
|
CMIP
|
Принцип
работы
|
Менеджер-агент
|
Менеджер-агент
|
Управляемый
объект
|
описание
управляемого ресурса, атрибут
|
описание
управляемого ресурса
|
Поддерживаемые
платформы
|
HP
Open View Network Node Manager, IBM Tivoli Net View, Sun
Solstice Domain Manager
|
Sun
Solstice Domain Manager
|
Осуществление
доступа к MIB
|
На
прямую через агента
|
Через
элемент CMSIE, услугами CMIS
|
Поддерживаемые
базы данных
|
Internet
MIB-||, MIB-|, DHCP MIB, RMON, RMON-2, WINS MIB
|
MIB
|
Формат
сообщения
|
UDP
|
UDP,
TCP
|
Доставка
сообщений
|
Без
гарантии
|
С
гарантией
|
Отправка
запросов
|
Только
к одному атрибуту одного объекта
|
Ко
многим атрибутам нескольких
объектов
|
Пройденные
уровни при передачи
|
Менеджер,
агент
|
менеджер,
CMIPM, ROSE, CMIPM, SMISE, агент
|
Время
выполнения операции с MIB
|
Малое
|
Большое
|
Возможность
извлечения нескольких значений
из MIB, а не одного
|
Операция
GetBulk
|
__________
|
Формирование,
передача запросов
|
Запрос
Get-Request
|
Услуга
ROSE(примитивы
RO-INVOKE, RO-RESULT, RO-ERROR, RO-REJECT)
|
Скорость
передачи сообщения
|
выше
|
ниже
|
Самостоятельность
элементов в сообщении об проблемах
сети
|
Операция
TRAP
|
__________
|
Архитектура
строения
|
простая
|
сложная
|
Надежность
|
Повторная
передача
|
Протокол
TCP
|
Безопасность
|
высока
|
низкая
|
СТАНДАРТЫ
СИСТЕМ УПРАВЛЕНИЯ СЕТЯМИ ТЕЛЕКОММУНИКАЦИЙ
НА ОСНОВЕ ПРОТОКОЛОВ TCP/IP
Телекоммуникационные
сети и вычислительные сети (сети
ЭВМ) являются очень сложными объектами,
которые нуждаются в эффективном
управлении. Поэтому помимо решений
ITU-T и ISO, касающихся управления сетями
электросвязи, в настоящее время
широко и активно используются
стандарты управления вычислительных
сетей для нужд управления
телекоммуникациями. При этом
преимущественно используются
протоколы TCP/IP, с подробным описанием
которых можно познакомиться в
многочисленной литературе
[17,20,21,34,42]. Среди протоколов этой
группы для управления используются
протоколы SNMPv
(Simple
Network
Management Protocol
- простой протокол сетевого управления,
v - варианты). Этот протокол определил
название модели сетевого управления,
в которую входят следующие элементы:
управляющая станция (менеджер сети);
агент управления, размещаемый в
сетевом элементе; информационная
база управления; протокол управления.
|