Для именования переменных базы MIB и однозначного определения их форматов используется дополнительная спецификация, называемая SMI — Structure of Management Information. Например, спецификация SMI включает в качестве стандартного имя IpAddress и определяет его формат как строку из 4 байт. Другой пример — имя Counter, для которого определен формат в виде целого числа в диапазоне от 0 до 232-1.
При описании переменных MIB и форматов протокола SNMP спецификация SMI опирается на формальный язык ASN.1, принятый ISO в качестве нотации для описания терминов коммуникационных протоколов (правда, многие коммуникационные протоколы, например IP, PPP или Ethernet, обходятся без этой нотации). Нотация ASN.1 служит для установления однозначного соответствия между терминами, взятыми из стандартов, предназначенных для человеческого использования, и теми данными, которые передаются в коммуникационных протоколах аппаратурой. Достигаемая однозначность очень важна для гетерогенной среды, характерной для корпоративных сетей. Так, вместо того чтобы указать, что некоторая переменная протокола представляет собой целое число, разработчик протокола, использующий нотацию ASN.1, должен точно определить формат и допустимый диапазон переменной. В результате документация на MIB, написанная с помощью нотации ASN.1, может точно и механически транслироваться в форму кодов, характерных для сообщений протоколов.
Нотация ASN.1 похожа на другие метаязыки, например нормальную Бэкусову форму, используемую при описании языков программирования, в частности Алгола. Нотация ASN.1 поддерживает базовый набор различных типов данных, таких как целое число, строка и т. п., а также позволяет конструировать из этих базовых типов составные данные — массивы, перечисления, структуры.
Существуют правила трансляции структур данных, описанных на ASN.1, в структуры данных языков программирования, например C++. Соответственно, имеются трансляторы, выполняющие эту работу. Примеры описаний данных с помощью ASN.1 приведены ниже при описании протокольных блоков данных SNMP. Нотация ASN.1 широко используется при описании многих стандартов OSI, в частности моделей управляемых объектов и структуры сообщений протокола CMIP.
Имена переменных MIB могут быть записаны как в символьном, так и в числовом форматах. Символьный формат используется для представления переменных в текстовых документах и на экране дисплея, а числовые имена — в сообщениях протокола SNMP. Например, символьному имени SysDescr соответствует числовое имя 1, а более точно 1.3.6.1.2.1.1.1.
Составное числовое имя объекта SNMP MIB соответствует полному имени этого объекта в дереве регистрации объектов стандартизации ISO. Разработчики протокола SNMP не стали использовать традиционный для стандартов Internet способ фиксации численных параметров протокола в специальном RFC, называемом «Assigned Numbers» (там описываются, например, численные значения, которые может принимать поле Protocol пакета IP, и т. п.). Вместо этого они зарегистрировали объекты баз MIB SNMP во всемирном дереве регистрации стандартов ISO, показанном на рис. 6.
Рис. 6. Пространство имен объектов ISO
Как и в любых сложных системах, пространство имен объектов ISO имеет древовидную иерархическую структуру, причем на рис. 6 показана только его верхняя часть. От корня этого дерева отходят три ветви соответствующие стандартам,контролируемым ISO, ITU и совместно ISO-ITU. В свою очередь, организация ISO создала ветвь для стандартов, создаваемых национальными и международными организациями (ветвь org). Стандарты Internet создавались под эгидой Министерства обороны США (Departament of Defence, DoD), поэтому стандарты MIB попали в поддерево dod-internet, а далее, естественно, в группу стандартов управления сетью — ветвь mgmt. Объекты любых стандартов, создаваемых под эгидой ISO, однозначно идентифицируются составными символьными именами, начинающимися от корня этого дерева. В сообщениях протоколов символьные имена не используются, а применяются однозначно соответствующие им составные числовые имена. Каждая ветвь дерева имен объектов нумеруется в дереве целыми числами слева направо, начиная с единицы, и эти числа и заменяют символьные имена. Поэтому полное символьное имя объекта MIB имеет вид: iso.org.dod.internet.mgmt.mib, a полное числовое имя: 1.3.6.1.2.1.
Группа объектов private (4) зарезервирована за стандартами, создаваемыми частными компаниями, например Cisco, Hewlett-Packard и т. п. Это же дерево регистрации используется для именования классов объектов CMIP и TMN.
Соответственно, каждая группа объектов MIB-I и MIB-II также имеет кроме кратких символьных имен, приведенных выше, полные символьные имена и соответствующие им числовые имена. Например, краткое символьное имя группы System имеет полную форму iso.org.dod.internet.mgmt.mib.system, а ее соответствующее числовое имя — 1.3.6.1.2.1. Часть дерева имен ISO, включающая группы объектов MIB, показана на рис. 7.
Рис. 7. Часть дерева имен ISO, включающая группы объектов MIB-I
Протокол SNMP обслуживает передачу данных между агентами и станцией, управляющей сетью. SNMP использует дейтаграммный транспортный протокол UDP, не обеспечивающий надежной доставки сообщений. Протокол, организующий надежную передачу дейтаграмм на основе соединений TCP, весьма загружает управляемые устройства, которые на момент разработки протокола SNMP были не очень мощные, поэтому от услуг протокола TCP решили отказаться.
SNMP часто рассматривают только как решение для управления сетями TCP/IP. Хотя SNMP чаще всего и работает над UDP (он может также работать и над TCP), он может работать и над транспортными сетевыми протоколами стека OSI — ТРО, ТР4, CNLS, а также над протоколами МАС-уровня. Растет поддержка протокола SNMP и в других транспортных средах. Например, фирма Novell начала поддерживать протокол SNMP с версии NetWare 3.11, а некоторые производители оборудования (например, Bay Networks) реализуют в своих устройствах передачу сообщений SNMP с помощью как IP, так и IPX.
Сообщения SNMP, в отличие от сообщений многих других коммуникационных протоколов, не имеют заголовков с фиксированными полями. В соответствии с нотацией ASN.1 сообщение SNMP состоит из произвольного количества полей, и каждое поле предваряется описателем его типа и размера.
Любое сообщение SNMP состоит из трех основных частей:
SNMP-Message ::=
SEQUENCE {
version INTEGER {
version-1 (0)
},
community
OCTET STRING,
SNMP-PDUs
ANY
}
Область данных может содержать пять различных типов PDU, соответствующих пяти командам протокола SNMP:
SNMP-PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU,
}
И наконец, для каждого типа PDU имеется определение его формата. Например, формат блока GetRequest-PDU описан следующим образом:
GetRequest-PDU ::=
IMPLICIT SEQUENCE {
request-id
Request ID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
Далее стандарт SNMP определяет соответственно формат переменных блока GetRequest-PDU.
Переменная Request ID — это 4-байтовое целое число (используется для установления соответствия ответов запросам), ErrorStatus и ErrorIndex — это однобайтовые целые, которые в запросе должны быть установлены в 0. VarBindList — это список числовых имен объектов, значениями которых интересуется менеджер. В нотации ASN.1 этот список состоит из пар «имя - значение». При запросе значение переменной должно быть установлено в null.
Вот пример сообщения протокола SNMP, которое представляет собой запрос о значении объекта SysDescr (числовое имя 1.3.6.1.2.1.1.1).
| 30 | 29 | 02 | 01 | 00 | --- | --- | --- |
| SEQUENCE | len=41 | INTEGER | len=41 | vers=0 | --- | --- | --- |
| 04 | 06 | 70 | 75 | 62 | 6C | 69 | 63 |
| string | len=6 | p | u | b | l | i | c |
| A0 | 1C | 02 | 04 | 05 | AE | 56 | 02 |
| getreq | len=28 | INTEGER | len=4 | --- | requested ID | --- | --- |
| 02 | 01 | 00 | 02 | 01 | 00 | --- | --- |
| INTEGER | len=1 | status | INTEGER | len=1 | error | index | --- |
| 30 | 0E | 30 | 0C | 06 | 08 | --- | --- |
| SEQUENCE | len=4 | SEQUENCE | len=12 | objectid | len=8 | --- | --- |
| 2B | 06 | 01 | 02 | 01 | 01 | 01 | 00 |
| 1.3 | 6 | 1 | 2 | 1 | 1 | 1 | 0 |
| 0.5 | 00 | --- | --- | --- | --- | --- | --- |
| null | len=0 | --- | --- | --- | --- | --- | --- |
Как видно из описания, сообщение начинается с кода 30 (все коды шестнадцатеричные), который соответствует ключевому слову SEQUENCE (последовательность). Длина последовательности указывается в следующем байте (41 байт). Далее следует целое число длиной 1 байт — это версия протокола SNMP (в данном случае О, то есть SNMP v.l, a 1 означала бы SNMP v.2). Поле community имеет тип string (строка символов) длиной в 6 байт со значением public. Остальную часть сообщения составляет блок данных GetRequest-PDU. То, что это операция Get-request, говорит код АО (это значение определено в протоколе SNMP, а не в нотации ASN.1), а общая длина блока данных — 28 байт. В соответствии со структурой блока Getrequest-PDU, далее идет идентификатор запроса (он определен как целое 4-байтовое число). Затем в блоке следуют два однобайтовых целых числа статуса и индекса ошибки, которые в запросе установлены в 0. И наконец, завершает сообщение список объектов, состоящий из одной пары — имени 1.3.6.1.2.1.1.1.0 и значения null.
