Концепция протокола SNMP

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

Административные связи протокола SNMP представлены на рис. 2.4. В архитектуре SNMP используется ряд терминов. Объекты, которые размещаются в центрах управления сетью и элементах сети и связываются друг с другом, используя протокол SNMP, называются объектами приложения SNMP (SNMP application entities) (см. рис. 2.4). Пары объектов приложения с агентами SNMP называются семейством SNMP (SNMP community). Каждое семейство идентифицировано в Internet иерархическим именем.

Рис. 2.4 - Административные связи SNMP

Сообщения SNMP порождаются объектами приложения SNMP. Они принадлежат семейству SNMP, которое содержит объект приложения. Эти сообщения названы подлинными сообщениями SNMP (Authentic SNMP messages). Для аутентификации используются схемы идентификации сообщения и верификации его подлинности. Этот процесс называется службой аутентификации (Authentication service).

Элемент SNMP использует объекты из IMIB. Подмножество объектов, имеющее отношение к этому элементу, называется представлением MIB SNMP (SNMP MIB view).

В свою очередь, элементам SNMP предписан определенный режим доступа (например, элементы только для чтения, элементы только для записи). Пара элементов с режимом доступа SNMP и представлением MIB называются профилем семейства SNMP (SNMP community profile) (см. рис. 2.5). В сущности, профили используются для определения привилегий доступа к представлениям MIB. Эти взаимосвязи, определяемые парой семейств SNMP при разработке профилей, называются стратегией доступа SNMP (SNMP access policies). Стратегия доступа обеспечивает затем правила, как агенты SNMP и элементы сети могут использовать MIB.

Рис. 2.5 - Профиль семейства SNMP

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

Алгоритм управления посредством опроса и реакции на событие

На рис. 2.6 показан процесс обычного прерывания. В этой ситуации ЦУС (помеченный, как «управление» в этой иллюстрации) реагирует на управляемый объект, когда управляемый объект посылает ему прерывание (interrupt). Прерывание является соглашением для управляющих коммуникаций между машинами. Устройство управления, после получения сообщения «Знать следующее», решает произвести некоторые действия и возвращает сообщение «Очень хорошо, делайте это...».

Рис. 2.6 - Операции опроса (Polling) и реакции на событие (Trap)

Прерывания не одобряются некоторыми проектировщиками, потому что они трудно предсказуемы. Поэтому и рабочая нагрузка на сети становится менее предсказуемой. Кроме того, прерывания могут повлечь за собой значительные перегрузки на блоки центральных процессоров сетевых компьютеров (Central processing units, CPU), потому что каждое прерывание должно обслуживаться с использованием циклов центрального процессора.

Напротив, в системах с обычным опросом (рис. 2.6) управляющая машина непрерывно посылает сообщения, называемые сообщениями опроса (Polling messages), или просто опросами (Polls) к МО.

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

Случай подхода SNMP с модифицированным прерыванием называется реакцией на событие (Trap) (см. рис. 2.6). Агент МО отвечает за выполнение проверок пороговых величин и уведомляет только о состояниях, которые не соответствуют некоторым пороговым критериям. Например, показания температурного датчика становятся слишком высокими, очереди существенно возросли, и т.д. После получения сообщения «Имеется необычное состояние» управляющая машина может произвести некоторые действия.

Преимущества этого подхода: (1) реакция на событие (прерывание) выполняется при очень немногих и критичных событиях, и (2) сообщение прерывания очень простое и короткое. Поэтому пропускная способность среды и такты CPU могут использоваться более эффективно.

Тем не менее, благоразумно продолжать использовать опрос (по крайней мере, периодически).

Уровни протокола SNMP

Для используемых протоколов уровня приложения, которые включены в стандарты сетевого управления OSI, синтаксис переноса разрабатывается организациями ISO и ITU-T.

Для однозначного описания данных в процессе переноса при сеансе связи используются стандарты ISO8824. Abstract Syntax Notation 1 (ASN.1) и ISO8825. Basic Encoding Rules (BER), в которых представлены система обозначений абстрактного синтаксиса и основные правила кодирования соответственно.

ASN.1 является языком для описания абстрактных синтаксисов пользователей OSI, каждая часть информации которых имеет тип (type) и величину (значение) (value). Типом являются такие признаки, как integer (целое), булево выражение, октет и т.д. Тип может быть использован для описания набора признаков. Например, тип integer описывает все значения, которые являются целыми. Величина описывает количество или часть алфавитного текста.

Стандарты описывают различные встроенные (внутренние) типы, которые представлены в табл. 3.1.

Таблица 3.1 Встроенные типы данных

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

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

Таблица 3.2 Номера тегов универсального класса для типов данных

Каждый тег определяется через его класс и номер. Определены четыре класса тегов:

- Универсальный: тип, не зависящий от приложения;

- Широкого применения: тип, который определяется применением и использованием в других стандартах (OSI, X.400 Message handling system (MHS), FT AM и т.д.);

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

- Частного использования: зарезервирован для частного использования (в стандартах не определяется).

Обобщенная архитектура ASN.1 представлена на рис. 3.2.

Рис. 3.2 - Обобщенная архитектура ASN.1

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

При использовании ASN.1 применяются простые, но важные правила:

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

- служебные слова, определенные в стандарте, всегда являются прописными; - конкретные имена могут начинаться со строчных букв. Они включены для облегчения понимания системы обозначений ASN. 1 и не влияют на дальнейшее кодирование;

- угловые скобки (< >) являются обозначением метки-заполнителя для актуальных элементов таких, как имя типа, имя модуля определенного типа, тело модуля и т.д.;

- знак «: : =» читается как «определить как»;

- правило представления модуля:

- <module name> DEFINITIONS: : = BEGIN

- <module body> END

Имя модуля (module name) идентифицирует модуль в соответствии с ASN. I. Определение (DEFINITION) модуля также должно соответствовать определениям ASN. 1 и размещается между словами НАЧАЛО (BEGIN) и КОНЕЦ (END). Внутри модулей определяются типы <type name>::=<type definitions. Это обозначение является примером простого типа, т.к. прямо специфицирует множество своих значений. Идентификатором типа является его имя. Пример кодирования трех типов определений внутри модуля представлен ниже:

<module name> DEFINITIONS::=BEGIN

<type name>: =<type definition

<type name>: =<type definition

<type name>:=<type definition>

END.

Это пример структурированного типа. Типы внутри структурированного типа называются типами компонентов.

Рис. 3.3 - Основные компоненты МО

Примеры определения основных компонентов МО представлены на рис. 3.3. Открывается пример квадратной скобкой 1. Базовый управляемый объект (Base Managed Object) определен как Последовательность (SEQUENCE) (см. табл. 3.1.), который является упорядоченным перечнем типов. Эти типы определены далее как Класс объекта (Object Class) и Инстанция объекта (Object Instance) с соответствующими именами, расположенными слева.

Они вставляются для удобства, не играют роли в кодировании значения типа и могут начинаться со строчных символов. Имя типа Object class определяется далее в уровне 2 рис. 3.3 как ВАРИАНТ (CHOICE). Это подразумевает, что значение типа CHOICE может быть только одним из предложенных внутри фигурных скобок, идентифицированных произвольными именами Global Form или non Specific Form. Класс CHOICE не имеет признака (см. табл. 3.1). Следовательно, каждый элемент в этом модуле должен быть снабжен признаком (в данном примере [0], [1]). Взамен признаков 6 и 2 типов данных OBJECT IDENTIFIER и INTEGER (см. табл. 3.1) здесь эти типы данных заново идентифицированы как 0 и 1.

Класс признаков (тегов), кроме универсального, указывается как служебное слово в квадратных скобках (например, [APPLICATION 4]). Однако, если не содержатся служебные слова Application или Private, то класс тегов является специфическим (context-specific). Это значит, что смысл значений может быть определен без дальнейшего определения и кодирования. Однозначным идентификатором любого объекта является значение OBJECT IDENTIFIER. Признак [0] определяет специфику идентификатора объекта. Тип Инстанция объекта определен в скобке 3. Новым обозначением при кодировании этого типа является Distinguished name (Различимое имя). При сетевом управлении OSI используется Различимое имя для однозначной идентификации объектов в MIT.

Документы Х.209 и ISO8825 описывают правила кодирования для типов и их значений в противоположность Х.208 и ISO8824, которые содержат абстрактные описания объектов. BER обеспечивают правила для соглашений синтаксиса переноса. Правила требуют, чтобы каждый тип описывался через хорошо сформированное, специфическое представление. Это представление называется элементом данных (data element) (или просто элемент). Как показано на рис. 3.4, он состоит из трех компонентов: типа (type), длины (length) и значения (value) - TLV, которые появляются в следующем порядке: Type Length Value.

Тип (type) также называется идентификатором. Он отличает один тип от другого (например, SEQUENCE от OBJECT IDENTIFIER) и определяет, каким образом интерпретировать остаток элемента. Длина специфицирует размер элемента. Значение (value), также известное как содержание (contents), содержит актуальную информацию элемента, такую, как различимое имя.

Длина может иметь одну из трех форм: короткую, длинную или неопределенную. Короткая форма состоит из 1 октета и используется, если L меньше, чем 128 октетов. Восьмой бит всегда является 0, биты с 7 по 1 указывают длину содержания. Длина определяется только размером содержания (значения) и не включает октеты, которые включают в себя октеты идентификатора и длины. Например, поле содержания в 22 октета описывается в поле L как

Длинная форма используется для поля более длинного содержания, равного или большего, чем 128, и меньшего, чем 21008 октетов. Неопределенная форма может быть использована, когда элемент является конструктором (правило для инициализации объекта). Это значение от 10000002 или 80i6. Для неопределенной формы специальный элемент end-of-contents (EOS) заканчивает содержание. Представлением ЕОС является 0000000016 .

Рис. 3.4 - Формат BER для элемента переноса

Содержание (значение) является актуальной информацией элемента. Оно описывается множеством из 8 бит и обладает переменной длиной. Содержание интерпретируется на основе кодирования поля идентификатора (Типа). Следовательно, содержание интерпретируется как строки бит, строки октетов и т.д. Как показано на рис. 3.4, элемент переноса может состоять из единственного TLV или серии элементов данных, описанных как множество TLV. Такая конструкция включает одно Т и одно L поля для определения полного протокольного блока данных, за которым следуют другие TLV поля, необходимые для кодирования данных. Элемент, состоящий из целого числа октетов п, записывается с наибольшего значения бита (Most significant bit, MSB), 8, слева и младшего бита (Least significant bit, LSB), 1, справа.

Тип, или идентификатор, из единичного октета кодируется, как показано на рис. 3.5. Биты 8 и 7 идентифицируют четыре типа классов признаков:

Универсальный 00

Широкого применения 01

Специфичный по контексту 10

Частного использования 11

Бит 6 идентифицирует форму (form) элемента данных. Возможны две формы. Примитивный элемент (primitive) (bit6=0) не имеет дальнейшей внутренней структуры элементов данных. Элемент - конструктор (constructor) (bit6=l) является рекурсивно определенным, содержащим серии элементов данных. Например, он может содержать сложные серии, которые определены как SEQUENCE (последовательность).

Оставшиеся 5 битов1 (от 5 до 1) различают один тип данных от другого в самом классе через использование номера тега. Если системе требуется более, чем 5 битов (число тега более, чем 30), биты с 5 по 1 первого октета кодируются 111102 и бит 8 последующих октетов как«1» для индикации использования следующих октетов и «0» для указания последнего используемого октета для указанной цели.

Все PDU SNMP имеют общий формат кода, основанного на ASN.1. На рис. 3.6 показано кодирование для общего формата.

Рис. 3.5 - Тип и определяемый формат

3.3 Примеры кода ASN.1 для протокольных блоков

Поле Request ID (ID Запроса) используется для отличия PDU, соответствующих различным запросам. Строка ErrorStatus (СтатусОшибки) открывает список типов ошибок, которые могут быть зафиксированы. К этому списку обращаются через поле Errorlndex (Индекс Ошибки), которое расположено ниже поля ErrorStatus (СтатусОшибки). В поле ErrorStatus (СтатусОшибки) перечислены типы ошибок. Строка noError (нет Ошибки) указывает на отсутствие ошибок.

В строке tooBig (большое Значение) сообщается, что результаты операции не могут быть закодированы в PDU SNMP. В строке noSuchName (Имя не идентифицировано) сообщается о том, что имя переменной не может быть идентифицировано. Строка badValue (неправильное Значение) используется, если переменная не может быть идентифицирована или ее синтаксис не понятен. В строке readonly (только для чтения) сообщается, что переменная быть только прочитана и не может быть записана. В строке genErr (другая Ошибка) сообщается о других ошибках.

Последовательность VarBind используется для идентификации имени управляемого элемента и любого связанного значения. VarBindList является компоновкой множества значений с множеством переменных. SNMP использует термин variable (переменные) для описания инстанции МО, и термин VarBind просто описывает пару - переменную и ее значение. VarBindList содержит список имен переменных и соответсвующие им значения.

Рис. 3.6 - Общее кодирование ASN.1 для протокольных блоков SNMP

На рис. 3.6 приведен пример кодирования ASN.1 протокольного блока Get Request. Параметры этого PDU были обсуждены ранее.

На рис. 3.8 показан код ASN.1 и другое изображение PDU (исключая PDU Trap). В правой части рисунка показан общепринятый метод изображения PDU.

Поля в PDU справа помечены в предположении, что самое верхнее поле передается первым, далее перемещаясь до нижней части рисунка. В более новых протоколах полагаются на описания полей в левой части рис. 3.7. Поля в PDU были описаны выше (см. рис. 3.7).

Рис. 3.7 - Кодирование ASN.1 протокольного блока Get Request

Рис. 3.8 - Код ASN.1 и изображение PDU SNMP (кроме Trap)

В стандартах Internet используются конструкции ASN.1 в IMIB для описания синтаксиса типов объектов. Разрешено использовать следующие типы примитивов ASN.l: INTEGER, OCTET STRING, OBJECT IDENTIFIER и NULL. Дополнительно к типам примитивов разрешено использование типов конструкций ASN.l: SEQUENCE и SEQUENCE OF.

В первоначальных стандартах были определены шесть крупных типов объектов Internet:

- Сетевой адрес (Network address): этот тип объектов позволяет выбирать семейство протоколов Internet. Он определяется в модифицированном обозначении ASN.1 как CHOICE (вариант), разрешающий смену протокола только внутри семейства протоколов Internet.

- IP адрес (IP address): этот тип используется для определения 32-битового адреса Internet. Его обозначением ASN.1 является OCTET STRING.