Архитектура протоколов для обмена управляющей информацией между менеджером и агентом 2 страница
В следующей части сообщения SNMP содержится заголовок конкретного PDU, причем для PDU типа Get, GetNext, Set, Response формат этого заголовка одинаков, а для сообщений Trapформат заголовка несколько иной (см. рис. 9).
Итак, рассмотрим элементы заголовков PDU типа Get, GetNext, Set, Response:
· Идентификатор PDU. Так как менеджер генерирует множество запросов, то для их идентификации используется данное поле. С помощью идентификатора запрсы и ответы на них связываются в пары (т.е. запрос и ответна данный запрос – имеют одинаковый идентивикатор). Может принимать значения от 0 до 232-1. Для запросов Get, GetNext и SET значение идентификатора запроса устанавливается менеджером и возвращается агентом объекта управления в отклике Response, что и позволяет связывать в пары запросы и ответы.
· Статус ошибки. Поле статус ошибки характеризуется целым числом (код ошибки), присланным объектом управления.
· Индекс ошибки. Если произошла ошибка, поле индекс ошибки (error index) характеризует, к какой из переменных это относится. Значение error index является указателем переменной и устанавливается агентом объекта управления не равным нулю для ошибок типа badvalue, readonly и nosuchname.
Таблица 2. Коды ошибок
| Статус ошибки | Имя ошибки | Описание |
| Noerror | Все в порядке; | |
| Toobig | Объект не может уложить отклик в одно сообщение; | |
| Nosuchname | В операции указана неизвестная переменная; | |
| badvalue | В команде set использована недопустимая величина или неправильный синтаксис; | |
| Readonly | Менеджер попытался изменить константу; | |
| Generr | Прочие ошибки. |
После указанных заголовков, следует информационная часть сообщения SNMP, в которой могут размещаться одна или более переменных, составляющих собственно управляющую информацию, запрашиваемую менеджером.
Кодирование всех элементов сообщений протокола SNMP, производится согласно правилам кодирования, специфицированным в рек. ITU-T Х.209 (BER – Basic Encoding Rules – базовые правила кодирования). В разделе 2.3 приводятся основные сведения об этих правилах.
Важно понимать, что каждый элемент сообщения, включая, те элементы, значения которых равно 0, кодируется как минимум тремя байтами по структуре T-L-V (Tag-Length-Value).
Для расшифровки полей пакета, относящихся к протоколу SNMP, необходимо познакомиться с основами языка ASN.1, который используется для описания информационных элементов (ИЭ), входящих в сообщения протокола SNMP, а также с правилами кодирования (BER), используемыми для кодирования сообщений протокола и ИЭ. Все сообщения протокола SNMP относятся к контекстно-зависимому классу тэгов (class tag=10) и имеют составной вид информационных элементов (constructor).
Для сообщений Trap, формат сообщения несколько отличается в части заголовка PDU:
| Заголовок SNMP | Заголовок PDU (для Trap) | Переменные (Идентификаторы объектов в MIB, значения параметров) | ||||||||||||||||||||
| Версия | Пароль (Community) | Тип PDU | Фирма (Enterprise) | Адрес объекта | Тип Trap | Спец. Код | Метка времени | Имя (Tag) | Длина (L) | Значение (Value) | ||||||||||||
| Vers – 1 | По умолчанию: public | См. табл.1 | OID | Network Address (IP-Address) | См. табл.3 | INTEGER | TimeTicks | *** | **** | Имя (Tag) | Длина (L) | … | ||||||||||
| T | L | V | T | L | V | T | L | V | T | L | V | T | L | V | … | … | … | T | L | T | L | V |
Рисунок 9 – Формат PDU-SNMP-Trap
Поясним назначение полей заголовка PDU-Trap:
Поле фирма (enterprise) – характиризует производителя опрашиваемого объекта;
В качестве адреса агента используются сетевыой адрес объекта, на котором установлень агент, в частности IP-адрес;
Тип ловушки (Trap) является целым числом, кодирующим один из следующих типов (см. табл 2):
Таблица 3 – Коды TRAP
| Код TRAP | Тип TRAP | Описание |
| Coldstart | Установка начального состояния объекта. | |
| Warmstart | Восстановление начального состояния объекта. | |
| Linkdown | Интерфейс выключился. Первая переменная в сообщении идентифицирует интерфейс. | |
| Linkup | Интерфейс включился. Первая переменная в сообщении идентифицирует интерфейс. | |
| Authenticationfailure | От менеджера получено SNMP-сообщение с неверным паролем (community). | |
| EGPneighborloss | EGP-партнер отключился. Первая переменная в сообщении определяет IP-адрес партнера. | |
| Entrprisespecific | Информация о TRAP содержится в поле специальный код. |
Для кодов TRAP 0…4 поле специальный код должно быть равно нулю.
Поле временная метка содержит число сотых долей секунды (число тиков) с момента инициализации объекта управления. Так прерывание coldstart выдается объектом через 200 мс после инициализации.
2.3 Способы кодирования сообщений протокола SNMP
2.3.1 Язык описания информационных элементов (объектов) – ASN.1
Информационная модель Системы управления представляется одной из самых сложных моделей и содержит огромное множество управляемых объектов, их атрибутов (свойств), действий (операций), реакций на действия и т.п. элементов.
В терминах информационной модели это множество объектов, отражающих различные свойства многообразных ресурсов, представлено абстрактным множеством информационных элементов (ИЭ), которые имеют конкретные значения, т.е. отличающиеся друг от друга элементы этого множества.
Значения (элементы) разделяются на типы, представляющие некоторое подмножество значений, которому присвоено имя.
МККТТ, учитывая:
· многообразие и сложность информационных объектов на прикладном уровне;
· необходимость нотации (записей о свойствах объектов) высокого уровня для абстрактного описания таких объектов;
· преимущества от выделения и стандартизации правил кодирования таких информационных объектов
рекомендует нотацию для определения абстрактного синтаксиса информационных объектов – ASN.1 (X.208), а также определяет типы и подтипы информационных объектов и правила кодирования – BER (Basic Encoding Rules - X.209).
Нотация ASN.1 широко используется при описании многих стандартовOSI, в частности моделей управляемых объектов, структуры сообщений протокола CMIP, OMAP и SNMP, переменных MIB, а также в качестве нотации для описания терминов информационных протоколов верхних уровней (например, FTP, MAP, INAP и т.п.).
Нотация ASN.1 служит для установления однозначного соответствия между терминами, взятыми из стандартов, предназначенных для использования человеком, и теми данными, которые передаются в коммуникационных протоколах.
Достигаемая однозначность очень важна для гетерогенной среды, характерной для современных сетей. Так, вместо того чтобы указать, что некоторая переменная протокола представляет собой определенное число, разработчик протокола, использующий нотацию ASN.1, должен определить формат и допустимый диапазон переменной. В результате документация на MIB, написанная с помощью нотации ASN.1, может механически транслироваться в форму кодов, характерных для сообщений протоколов верхних уровней.
Нотация ASN.1 похожа на другие метаязыки, используемые при описании языков программирования, в частности С++.
Нотация ASN.1 поддерживает базовый набор различных типов данных, таких как целое число, строка и т. п., а также позволяет конструировать из этих базовых типов составные данные — массивы, списки, структуры.
В ASN.1 типы и значения выражаются в нотации, близкой к используемой в языках программирования. Идентификаторы объектов (имена значений и полей) и имена типов состоят из букв, цифр и пробелов. Идентификаторы начинаются со строчной буквы, а имена типов - с прописной.
В ASN.1 используются следующие символы:
| Символы от A до Z |
| Символы от a до z |
| Символы от 0 tдо 9 |
| Символы : = , { } < . |
| Символы( ) [ ] - ' ” |
В ASN.1 зарезервированы следующие последовательности символов (служебные слова)
| BOOLEAN | OPTIONAL | INCLUDES |
| INTEGER | DEFAULT | MIN |
| BIT | COMPONENTS | MAX |
| STRING | UNIVERSAL | SIZE |
| OCTET | APPLICATION | FROM |
| NULL | PRIVATE | WITH |
| SEQUENCE | TRUE | COMPONENT |
| OF | FALSE | PRESENT |
| SET | BEGIN | ABSENT |
| IMPLICIT | END | DEFINED |
| CHOICE | DEFINITIONS | BY |
| ANY | EXPLICIT | PLUS-INFINITY |
| EXTERNAL | ENUMERATED | MINUS-INFINITY |
| OBJECT | EXPORTS | TAGS |
| IDENTIFIER | IMPORTS |
Существуют правила трансляции структур данных, описанных на ASN.1, в структуры данных языков программирования, например C++. Соответственно, имеются трансляторы, выполняющие эту работу.
ASN.1 описывает несколько способов описания типов данных (ИЭ). Прежде всего, это использование простых и составных типов данных.
ASN.1 различает следующие типы ИЭ:
· Простой тип (тип-примитив) – определяется прямым заданием (описанием) множества составляющих его значений;
· Структурированный (составной) тип (тип-конструктор) – это тип, при определении которого используются ссылки на другие типы. Фактически, структурированный тип – это своеобразная «матрешка», содержащая внутри себя ИЭ как простого типа, так и составного типа, что придает такой конструкции высокую гибгость, при описании большого числа взаимосвязанных переменных (например, баз данных управляющей информации – MIB). Число вложений в «матрешку» не ограничено, как не ограничено число ветвей дерева MIT.
В ASN.1 определено несколько структурированных типов ИЭ, например:
| SEQUENCE | Упорядоченная последовательность из одного или более других типов ИЭ. |
| SET | Неупорядоченный набор из одного или более других типов ИЭ. |
| CHOICE | Набор из заданного списка возможных типов ИЭ |
| SEQUENCE OF | Одномерный массив ИЭ одного типа |
Каждому типу в ASN.1 присвоено обозначение, выраженное в виде ТЭГА (англ. – TAG, русские синонимы – указатель, индикатор, метка, описатель).
ASN.1 определяет 4 класса тэгов (описателей).
· 1 класс – Универсальный (UNIVERSAL - UNI) – используется в ASN.1 (X.208) и присваивается либо одному типу данных, либо способу построения типов.
· 2 класс – Прикладной (общеприкладной – APPLICATION-WIDE – APP-W) – присваивается типам данных, определенных в других стандартах или Рекомендациях (например, в рек. Х.500 для службы каталогов).
· 3 класс – Контекстно-зависимый (CONTEXT-SPECIFIC – C-SPEC) – эти тэги могут назначаться любым типам данных и интерпретируются в соответствии с контекстом, в котором они используются.
· 4 класс – Пользовательский (частный – PRIVATE - PRIV) – присваивается типам данных, определенных различными организациями, а не стандартами ISO или Рекомендациями МККТТ.
2.3.2 Базовые правила кодирования информационных элементов – BER
В ASN.1 определены правила преобразования значений переменных (ИЭ) в последовательность байтов для последующего обмена по сети. Называются эти правила – базовые правила кодирования (BER – см. рек. ITU-T Х.209).
Каждое передаваемое значение ИЭ кодируется тремя полями (так называемая конструкция T-L-V=Tag-Length-Value):
1. Идентификатор ИЭ (Тэг) - Определяет класс и тип ИЭ, а также указывает, является ли метод кодирования примитивным или составным.
2. Длина поля данных - определяет число октетов содержимого.
3. Значение (Содержимое) поля данных (Value, Content) – т.е. сущность или конкретное выражение значения ИЭ.
| T | L | V |
| Тэг | Длина | Значение (Содержимое) |
Таким образом, перед передачей содержимого любого ИЭ, включая значение «0», передается Тэг, кратко поясняющий тип данных в поле содержимое, и длина поля «Содержимое», выраженная в байтах и записанная в поле «Длина».
Дадим более детальныю характеристику этим полям.
2.3.2.1 Идентификатор типа объекта (Тэг).
Поле Tag представляется 8-ми битовым кодом (см. рис.2-1), 2 старших бита (7-й и 8-й), которого указывают класс тэга (см. рис.10).
| Тэг | Длина | Содержимое (Content) |
Рисунок 10 – Структура Тэга
Таблица 4 – Кодирование Класса тэгов (7-й и 8-й биты)
| Класс | Бит 8 | Бит 7 | |
| Универсальный | UNI | ||
| Прикладной | APP | ||
| Контекстно-ориентированный | C-SP | ||
| Частный | PRIV |
6-й бит тэга указывает тип ИЭ. Возможно два типа данных ИЭ:
· простой тип данных ИЭ (p - primitive) – значение 6-го бита “0”,
· составной тип данных ИЭ (c - constructor) – значение 6-го бита “1”.
Для составных типов данных, характерна конструкция «матрешки»:
T – L - ( T – L - (T – L (…V)))
Типичными значениями составных данных являются:
· последовательности данных (Sequence),
· наборы данных (Set),
· выбор из набора (ассортимента) данных (Choice).
Оставшиеся 5 бит тэга могут использоваться для кодирования значений (номера) тэга. Причем этих 5 бит достаточно для записи кода не превышающего значения 30 (11110’Bin). Если значения 5 бит заполняются “1”, то используется многобайтовая структура тэга, при этом реальное значение кода тэга указывается в следующем байте или байтах.
Для универсального класса (UNI) предусмотрено не больше 30 кодов тэгов, описанных в рек. ITU-T Х.208 (см. табл. 5).
Таблица 5 – Назначенные коды тэгов класса UNI
| Класс (биты 8 и 7) | p/c ( бит 6) | Код (биты 54321) | Типы данных в поле «содержимое» | Tag ‘hex |
| UNI (00) | 00001’Bin или 1’Dec | Boolean type | ||
| UNI (00) | 00010’Bin или 2’Dec | Integer type | ||
| UNI (00) | 00011’Bin или 3’Dec | Bitstring type | ||
| UNI (00) | 00100’Bin или 4’Dec | Octetstring type | ||
| UNI (00) | 00101’Bin или 5’Dec | Null type | ||
| UNI (00) | 00110’Bin или 6’Dec | Object identifier type | ||
| UNI (00) | 7’Dec | Object descriptor type | ||
| UNI (00) | 8’Dec | External type | ||
| UNI (00) | 9’Dec | Real type | ||
| UNI (00) | 10’Dec | Enumerated type | 0a | |
| UNI (00) | 12…15’Dec | Reserved for future versions | ||
| UNI (00) | 16’Dec | Sequence and Sequence-of types | ||
| UNI (00) | Set and Set-of types | |||
| UNI (00) | 0/1 | 18…22 25…27 | Character string types (например, последовательность символов в коде IA5) | 12/32 |
| UNI (00) | 23, 24 | Time types | 17, 18 | |
| UNI (00) | 28… | Reserved for future versions |
Для других классов тэгов существуют свои способы кодирования, рассматриваемые в соответствующих документах.
Например, в рек. ITU-T Q.773 рассматривается как универсальный класс тэгов (00), так и прикладной (01) для протокола TCAP. Например, для таких информационных элементов, как тип сообщения протокола ТСАР используются следующие номера тэгов из класса «Прикладной» (01) – см. табл.6.
Таблица 6 – кодирование типов сообщений в классе тэгов «Прикладной или 01» для протокола ТСАР (Q.773 ITU-T)
| \номер бита в тэге | |||||||||
| Тэг’hex | Тип сообщения | Класс тэга | Тип | Номер тэга | |||||
| 61’hex | Unidirectional | ||||||||
| 62’hex | Begin | ||||||||
| 63’hex | (reserved) | ||||||||
| 64’hex | End | ||||||||
| 65’hex | Continue | ||||||||
| 66’hex | (reserved) | ||||||||
| 67’hex | Abort |
В рек. ITU-T X.219, X.229 рассматриваются услуги протокола ROSE и соответствующие операции. Для кодирования этих информационных элементов (операций) используется класс тэгов контекстно-зависимый (C-SP или 10).
Пример кодирования этих операций приведен в табл. 7
Таблица 7 – Кодирование тэгов для операций протоколов ROSE, TCAP.
| \номер бита в тэге | |||||||||
| Тэг’hex | Тип операции | Класс тэга | Тип | Номер тэга | |||||
| a1’hex | Invoke | ||||||||
| a2’hex | Return Result (Last) | ||||||||
| a3’hex | Return Error | ||||||||
| a4’hex | Reject | ||||||||
| a5’hex | (reserved) | ||||||||
| a6’hex | (reserved) | ||||||||
| a7’hex | Return Result (Not Last) |
Подобный же класс тэгов (контекстно-зависимый или 10) используется для кодирования операций (команд, сообщений или PDU) в протоколе SNMP (стандарт IETF RFC-1155) – см. табл.8.
Таблица 8 – Кодирование тэгов для PDU протокола SNMP.
| \номер бита в тэге | |||||||||
| Тэг’hex | Тип операции (PDU) | Класс тэга | Тип | Номер тэга | |||||
| a0’hex | GET-request | ||||||||
| a1’hex | GET_next_request | ||||||||
| a2’hex | GET response | ||||||||
| a3’hex | SET-request | ||||||||
| a4’hex | TRAP |
2.3.2.2 Длина поля данных
Возможно два способа представления этого поля:
1. Краткая форма (см. рис.11). Используется, если длина поля данных (содержимого) не превышает 127 байт. В этом случае старший (8-й) бит поля «длина» имеет значение «0», а в остальных семи битах записывается реальная длина поля данных в байтах, причем младшим (наименее значащим битом - LSB), является 1-й бит, а старшим (наиболее значащим битом - MSB), является 7-ой бит.
| Номер бита | ||||||||
| Значение бита | MSB | LSB | ||||||
| Длина поля данных (в байтах) |
Рисунок 11 – Краткая форма поля «Длина»
Например, если содержимое имеет длину 38 байт, то значение поля «Длина», будет следующим:
L= 00100110’Bin (38’Dec)
2. Длинная форма (см. рис.12). Используется, если длина поля данных (содержимого) более 127 байт. В этом случае старший (8-й) бит поля «длина» имеет значение «1», а в остальных семи битах первого байта записывается целое число, равное количеству байт в поле «Длина» - 1. Реальная длина поля данных, выраженная в байтах, записывается в последующих байтах поля «Длина». При этом, младшим (наименее значащим битом - LSB), является 1-й бит последнего байта, а старшим (наиболее значащим битом - MSB), является 8-ой бит первого байта.
| Номер бита | |||||||
| MSB | LSB | ||||||
| количество байт в поле «Длина» -1 | |||||||
| MSB | |||||||
| … | |||||||
| количество байт в поле «Содержимое» | |||||||
| LSB |
Рисунок 12 – Длинная форма поля «Длина»
Пример 1: если содержимое имеет длину 219 байт, то значение поля «Длина», будет следующим:
1-й байт - 10000001’Bin– указывает длину поля «Длина» (1 байт)
2-й байт - 11011011’Bin– указывает длину поля «Содержимое» (219 байт)
Пример 2: если содержимое имеет длину 1347 байт, то значение поля «Длина», будет следующим:
1-й байт - 10000010’Bin– указывает длину поля «Длина» (2 байта)
2-й байт - 00000101’Bin– эти байты указывают длину поля
3-й байт - 01000011’Bin«Содержимое» (1347 байт)
Или в другом виде эту запись можно представить так:
Й байт 2-й байт 3-й байт
Hex
10000010 00000101 01000011’Bin=1347’Dec