Сравнительная характеристика различных протоколов управления

His

RESEARCH

Сравнительная характеристика различных протоколов управления

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

Ключевые слова: информация, каналы, беспроводные сети, стандарт, алгоритм.

Легков К.Е.,

Северо-Кавказский филиал Московского технического университета связи и информатики

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

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

Широко распространённые в настоящее время системы сетевого управления, работающие на базе протокола SNMP (Simple Network Management Protocol), являются сильно упрощёнными с "точки зрения" TMN. Протокол SNMP обеспечивает, прежде всего, мониторинг сети и сбор статистических данных, т. е. реализует функцию Fault Management. Другие функции, такие как Performance и Configuration Management, в стандартных реализациях SNMP, как правило, отсутствуют. Это связано с тем, что, несмотря на введение дополнительных средств обеспечения безопасности в классический SNMPv2, вопрос о защищённости системы от попыток "взлома" остаётся открытым, прежде всего из-за примитивности протокола

SNMP и его жёсткой привязки к транспортным службам. Обычно в гражданских системах производители оборудования создают собственные SNMP-подобные протоколы для реализации функций Performance и Configuration Management и, тем самым, уходят от стандартных решений. Системы управления перестают быть простыми, стандартными и общими в использовании средствами для управления сетями связи. Более того, продолжающие возрастать сложность и комплексность базирующихся на SNMP систем управления такими сетями, как ATM, сближает их с системами управления, построенными по принципам TMN.

TMN как концепция управления сетью подразумевает, прежде всего, ряд профилактических работ, направленных на поддержание сети в работоспособном состоянии. Эти работы выполняются с помощью так называемой системы эксплуатации и технического обслуживания сети (Operation, Administration and Maintenance, OA&M). Рассмотрим перечень протоколов, действующих в рамках данной концепции.

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

Обычно при использовании SNMP присутствуют управляемые и управляющие системы. В состав управляемой системы входит компонент, называемый агентом, который отправляет отчёты управляющей системе. По существу SNMP агенты передают управленческую информацию на управляющие системы как пере-

Comparative characteristic of different protocols of control

Legkov K.E.,

North Caucasian branch of the Moscow technical university of communication and informatics

Abstract

There is a set of different network protocols of the control, allowing to make distant monitoring of electronic devices. These protocols can correspond to different OSI levels and provide different ranges of services.

Keywords: information, channels, wireless networks, standard, algorithm.

His

К E S E A H С II

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ

менные (такие как "свободная память", "имя системы", "количество работающих процессов").

Управляющая система может получить информацию через операции протокола: GET, GETNEXT и GETBULK. Агент может самостоятельно без запроса отправить данные, используя операцию протокола TRAP или INFORM. Управляющие системы могут также отправлять конфигурационные обновления или контролирующие запросы, используя операцию SET для непосредственного управления системой. Операции конфигурирования и управления используются только тогда, когда нужны изменения в сетевой инфраструктуре. Операции мониторинга обычно выполняются на регулярной основе.

Переменные, доступные через SNMP организованы в иерархии. Эти иерархии и другие метаданные (такие, как тип и описание переменной) описываются Базами Управляющей Информации (MIB — Management Information Base).

SNMP не определяет, какую информацию (какие переменные) управляемая система должна предоставлять. Наоборот, SNMP использует расширяемую модель, в которой доступная информация определяется MIB. Базы Управляющей Информации описывают структуру управляющей информации устройств. Они используют иерархическое пространство имён, содержащее уникальный идентификатор объекта (англ. object identifier (OID)). Грубо говоря, каждый уникальный идентификатор объекта идентифицирует переменную, которая может быть прочитана или установлена через SNMP MIB используют нотацию, определённую в ASN.1. Эта модель обеспечивает управление на всех слоях сетевой модели OSI, так как MIB могут быть определены для любых типов данных и операций.

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

Существует два типа управляемых объектов:

— скалярные объекты определяют единственный экземпляр объекта;

— табличные объекты определяют множественные, связанные экземпляры объектов которые группируются в таблицах MIB.

Идентификатор объекта (OID) уникально идентифицирует управляемый объект в иерархии MIB.

В телекоммуникациях и компьютерных сетях, ASN.1 является стандартной гибкой нотацией для описания структур данных, служащих

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

ASN.1 это единый ISO и ITU-T стандарт, изначально определённый в 1984 году как часть стандарта CCITT X.409:1984. Позже, в 1988 году, из-за его широкой применимости, он был выделен в отдельный стандарт X.208. Значительно пересмотренная версия 1995 года описана в X.680.

Адаптированное подмножество ASN.1 Структура Управляющей Информации (SMI) специфицировано в протоколе SNMP для определения наборов связанных MIB объектов, также называемых MIB модулями.

CMIP — стандарт управления сетью OSI. Он определяет некоторые функции, отсутствующие в SNMP и SNMPv2. В силу своей сложности CMIP имеет гораздо меньшее распространение и привлекает гораздо меньший интерес, нежели SNMP но иногда его использование необходимо. При этом данный протокол управления также основывается на использовании MIB.

Протоколы управления, основывающиеся на MIB, являются довольно жесткими по своей структуре — MIB полностью задает перечень регулируемых параметров, который, в общем случае, не является одинаковым для средств сети. Также в общем случае потребуются специальные механизмы для обеспечения взаимосвязанных параметров, алгоритмы защиты данных в момент записи информации (с целью обеспечения корректного считывания) и обеспечение усиленных мер безопасности. Также протоколы SNMP и CMIP опираются на использование широко распространенных протоколов транспортного уровня, использующихся в проводных компьютерных сетях, а значит, потребуют новой реализации, с целью обеспечения стыковки с разрабатываемым в рамках тома части настоящей пояснительной записки стека протоколов. Также данные средства не предусматривают универсального решения по методам защиты информации, что также потребует их доработки для возможности использования с разрабатываемыми средствами защиты информации.

TELNET (англ. TErminaL NETwork) — сетевой протокол для реализации текстового интерфейса по сети (в современной форме — при помощи транспорта TCP). Название "telnet" имеют также некоторые утилиты, реализующие клиентскую часть протокола. Современный стан-

дарт протокола описан в RFC 854.

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

Хотя в сессии Telnet выделяют клиентскую и серверную сторону, протокол на самом деле полностью симметричен. После установления транспортного соединения (как правило, TCP) оба его конца играют роль "сетевых виртуальных терминалов" (англ. Network Virtual Terminal, NVT), обменивающихся двумя типами данных:

— прикладными данными (т.е. данными, которые идут от пользователя к текстовому приложению на стороне сервера и обратно);

— командами протокола Telnet, частным случаем которых являются опции, служащие для уяснения возможностей и предпочтений сторон.

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

Прикладные данные проходят через протокол без изменений, т.е. на выходе второго виртуального терминала мы видим именно то, что было введено на вход первого. С точки зрения протокола данные представляют просто последовательность байтов (октетов), по умолчанию принадлежащих набору ASCII, но при включенной опции Binary — любых. Хотя были предложены! расширения для идентификации набора символов, но на практике ими не пользуются.

Все значения октетов прикладных данных кроме 3778 (десятичное 255) передаются по транспорту как есть. Октет 3778 передаётся последовательностью 37783778 из двух октетов. Это связано с тем, что октет 3778 используется на транспортном уровне для кодирования опций.

Протокол предоставляет по умолчанию минимальную функциональность и набор расширяющих её опций. Принцип оговоренных опций требует проводить переговоры! при включении каждой из опций. Одна сторона инициирует запрос, а другая сторона может либо принять, либо отвергнуть предложение. Если запрос принимается, то опция немедленно вступает в силу. Опции описаны отдельно от протокола как такового, и их поддержка программным обеспечением произ-

Наукоёмкие технологии в космических исследованиях Земли № 1-2010

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

Принтер NVT имеет неопределённую ширину каретки и длину страницы и должен иметь представление всех 95 печатных символов US-ASCII (коды с 32 по 126). Управляющие символы имеют следующие значения:

Поддержка действия символов, помеченных как*, протоколом Telnet обязательна. Прочие могут производить заданное действие или не производить никакого; одна сторона не должна предполагать ничего определённого о поддержке конкретных необязательных управляющих символов другой стороной.

Последовательность "CR LF" должна обрабатываться как единый символ перевода строки и использоваться всякий раз, когда требуется их объединённое действие; последовательность "CR NUL" должна использоваться, где требуется только возврат каретки; и использования символа CR следует избегать в других контекстах.

Каждая команда TELNET является многобайтовой последовательностью, начинающейся с кода 3778 (десятичное: 255) "Interpret as Command" (IAC) и кода команды. Команды, отвечающие за договоренности по опции, явля-

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

Исторически Telnet служил для удалённого доступа к интерфейсу командной строки операционных систем. Иногда клиенты telnet используются для доступа к другим протоколам на основе транспорта TCR

Протокол telnet используется в управляющем соединении FTP, то есть заходить на сервер командой telnet ftp.example.net ftp для выполнения отладки и экспериментов не только возможно, но и правильно (в отличие от применения клиентов telnet для доступа к HTTP, IRC и большинству других протоколов).

В протоколе не предусмотрено использование ни шифрования, ни проверки подлинности данных. Поэтому он уязвим для любого вида атак, к которым уязвим его транспорт, то есть протокол TCR Для функциональности удалённого доступа к системе в настоящее время применяется сетевой протокол SSH (особенно его версия 2), при создании которого упор делался именно на вопросы безопасности. Сессия Telnet весьма беззащитна, если только не

Таблица 1

осуществляется в полностью контролируемой сети или с применением защиты на сетевом уровне (различные реализации виртуальных частных сетей). По причине ненадёжности от Telnet, как средства управления операционными системами, давно отказались.

Такие программы как netcat обеспечивают чистый доступ к TCP однако требуются специальные ухищрения (как то stty -icrnl на UNIX-системе) для передачи перевода строки как CR LF (что требуется многими протоколами). Обычно клиент Telnet по умолчанию передаёт любой перевод строки как CR LF, независимо от его кодирования в системе клиента. Также для отладочного доступа к прикладным протоколам (кроме FTP и, собственно, Telnet) является использование клиента PuTTY в режиме "Raw" (чистый доступ к TCP) — PuTTY преобразует переводы строки отдельно от поддержки протокола Telnet.

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

Помимо перечисленного стоит отметить, что для осуществления любого управления радиосредствами по каналам связи, необходимо иметь информацию о их ключевой структуре и быть снабженным СКЗИ, с возможностью закрытия информации, предназначающийся одному из множества абонентов, на соответствующий ключ. Кроме того, для осуществления открытия пакетов данных необходимо, чтобы СКЗИ, которым обладает лицо, желающее производить управление средством удаленно, в обход ПУРС, было зарегистрировано в каждом управляемом средстве. Таким образом, подобное управление возможно исключительно в ситуациях подключения вычислительного средства к радиосредствам. Существование нескольких точек управления и мониторинга не унифицированного вида серьезным образом увеличит объем передаваемого по сети трафика (приблизительно во столько раз сколько существует точек управления и контроля), а также

Перечень управляющих символов протокола TELNET

Название Код (десятичный/шестнадцатеричный) Описание

NULL (NUL)* 0/0x00 Нет операции

Line Feed (LF)* 10/0x0 A Переводит принтер на следующую строку печати, оставаясь на той же горизонтальной позиции.

Carriage Return (CR)* 13/0x0D Перемещает принтер к левой границе текущей строки.

BELL (BEL) 7/0x07 Производит аудио или видеосигнал (но НЕ перемещает головку принтера).

Back Space (BS) 8/0x08 Перемещает головку принтера на один символ по направлению к левой границе.

Horizontal Tab (HT) 9/0x09 Перемещает принтер на следующую остановку горизонтальной табуляции. Остается неопределённым как сторона определяет и устанавливает эти остановки табуляции.

Vertical Tab (VT) 1 l/0x0B Перемещает принтер на следующую остановку вертикальной табуляции. Остается неопределённым как сторона определяет и устанавливает эти остановки табуляции.

Form Feed (FF) 12/0x0C Перемещает принтер к верхней части следующей страницы, оставаясь на той же горизонтальной позиции.

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ

HiS

RESEARCH

Таблица 2

Перечень кодов и кодовых последовательностей, имеющих смысл при следовании сразу за 1АС

Название Код (десятичный/шестнадцатеричный) Описание

SE 240/0xF0 Завершает согласование, начатое командой SB

NOP 241/OxFl Нет операции.

Data Mark 242/0xF2 Синхронизация (Synch) обмена данными. Эта команда всегда сопровождается TCP Urgent notification.

Break 243/0xF3 Нажата кнопка «Break» или «Attention».

Interrupt Process 244/0xF4 Приостанавливает, прерывает, аварийно прекращает или завершает процесс.

Abort output 245/0xF5 Подавление вывода текущего процесса. Также отправляет сигнал Synch пользователю.

Are You There 246/0xF6 Отправляет обратно ответ терминала, состоящий из печатных символов.

Erase character 247/0xF7 Получатель должен удалить предыдущий символ, если это возможно.

Erase Line 248/0xF8 Стереть последнюю введённую строку, то есть все данные, полученные после последнего перевода строки.

Go ahead 249/0xF9 Ожидается передача данных.

SB 250/0xFA Начало согласования опции, требующего передачи параметров.

WILL опция 251/OxFB Указывает на желание исполнять или подтверждает, что сейчас исполняется указанная опция.

WON'T опция 252/OxFC Указывает на отказ начать или продолжить исполнять указанную опцию.

DO опция 253/OxFD Запрос на то, чтобы другая сторона исполнила или подтвердила исполнение указанной опции.

DON'T опция 254/OxFE Требование на то, чтобы другая сторона остановила исполнение или подтвердила то, что указанная опция более не исполняется.

IAC 255/OXFF Байт данных 255.

усложнит алгоритмы управления обоими комплексами. Кроме того, предоставление таких возможностей лицам, использующим сторонние вычислительные средства для управления, снижает уровень безопасности в системе до самого слабого из существующих уровней — собственно ПЭВМ, не обладающей заранее определенным уровнем контроля доступа, защитой от НСД и др. Также данное решение вынуждает радиосредства обладать возможнос-

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

XML-RPC — стандарт/протокол вызова удалённых процедур, основанный на XML, прародитель SOAP, отличается исключительной

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

XML-RPC основывается на XML -языке разметки, фактически представляющим собой свод общих синтаксических правил. XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML). XML является упрощённым подмножеством языка SGML.

SGML заявил о себе как гибкий, комплексный и всеохватывающий мета-язык для создания языков разметки. Несмотря на то, что понятие гипертекста появилось в 1965 году, SGML не имеет гипертекстовой модели. Создание SGML можно с уверенностью назвать попыткой объять необъятное, так как он объединяет в себе такие возможности, которые крайне редко используются все вместе. В этом и состоит его главный недостаток — сложность и, как следствие, дороговизна этого языка.

Наиболее широко SGML применяется для создания других языков разметки, именно с его помощью был создан язык разметки гипертекстовых документов — HTML, спецификация которого была утверждена в 1992 году. Его появление было связано с необходимостью организации стремительно увеличивающегося массива документов в сети Интернет. Бурный рост количества подключений к Интернету и, соответственно, веб-серверов повлек за собой такую потребность в кодировке электронных документов, с которой не мог справиться SGML вследствие высокой трудности освоения. Появление HTML — очень простого языка разметки — быстро решило эту проблему: лёгкость в изучении и богатство средств оформления документов сделали его самым популярным языком для пользователей Интернет. Но, по мере роста количества и изменения качества документов в Сети, росли и предъявляемые к ним требования, и простота HTML превратилась в его главный недостаток. Ограниченность количества тегов и полное безразличие к структуре документа побудили разработчиков в лице консорциума W3C к созданию такого языка разметки, который был бы не столь сложен, как SGML, и не настолько примитивен, как HTML. В резуль-

Наукоёмкие технологии в космических исследованиях Земли № 1-2010

y s

RESEARCII

Таблица 3

Перечень типов XML-RPC

Имя типа Пример тега Описание типа

array <array> <data> <value><i4> 1404</i4></value> <value><string>4To-Hn6yzib здесь</string></value> <value><i4> 1 </i4></value> </data> </array> Массив величин, без ключей

base64 <base64>eW91 IGNhbidOIHJl YWQgdGhpcyE=</base64> Кодированные в Вазе64 двоичные данные

boolean <boolean> 1 </boolean> Логическая

date/time <dateTime.iso8601>19980717T14:08:55</dateTime.iso8601> Дата и время

double <double>-12.5 3 </ double> Дробная величина двойной точности

integer <i4>42</i4> Целое число

string <string>3flpaBCTByii, Mnp!</string> Строка символов

struct <struct> <member> <пате>Что-то</пате> <value><i4> 1 </i4></value> </member> <member> <пате>Ещё что-то</пате> <value><i4>2</i4></value> </member> </struct> Массив величин, с ключами

nil <nil/> Нулевая (пустая) величина — это расширение ХМЕ-КРС

тате на свет появился язык XML, сочетающий в себе простоту HTML, логику разметки SGML и удовлетворяющий требованиям Интернета.

Стандартом определены два уровня правильности документа XML:

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

Действительный. Действительный документ дополнительно соответствует некоторым се-

мантическим правилам. Это более строгая дополнительная проверка корректности документа на соответствие заранее определённым, но уже внешним правилам, в целях минимизации количества ошибок, например, структуры и состава данного конкретного документа или семейства документов. Эти правила могут быть разработаны как самим пользователем, так и сторонними разработчиками, например, разработчиками словарей или стандартов обмена данными. Обычно такие правила хранятся в специальных файлах — схемах, где самым подробным образом описана структура документа, все допустимые названия элементов, атрибутов и многое другое. И если документ, например, содержит не определённое заранее в схемах название элемента, то XML-документ считается недействительным; проверяющий

XML-процессор (валидатор) при проверке на соответствие правилам и схемам обязан (по выбору пользователя) сообщить об ошибке.

XML — это описанная в текстовом формате иерархическая структура, предназначенная для хранения любых данных. Визуально структура может быть представлена как дерево элементов. Элементы XML описываются тегами.

Таким образом, XML-RPC предоставляет собой гибкий, простой к реализации протокол почти не накладывающий никаких ограничений на его фактическую реализацию. С использованием специальных методов сжатия, которые будут распространены по каждому радиосредству, таких как словарные методы сжатия данных, с заранее фиксированным словарем, оптимизированным под словарь XML формата, можно добиться хороших результатов сжатия данных. Все управляющие сигналы можно составить таким образом, что результаты его влияния на различные устройства будут соответствовать требованиям к их воздействиям.

Таким образом, предпочтительным является выбор в качестве протокола управления XML-RPC, ключевые особенности которого позволят управлять большим количеством средств без существенных затрат емкостей каналов, а его простота позволит быстро разбирать команды управления.

Литература

1. IEEE Std 802.11-2007, Revision of IEEE Std 802.11-1999. IEEE Std 802.11-2007, IEEE Standard for Information Technology — Telecommunications and information exchange between systems — Local and metropolitan areanetwork-Specific requirements — Part 11: Wireless IAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. IEEE Computer Society, June 2007.

2. IEEE P802.11s/D2.0. Draft STANDARD for Information Technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 11: Wireless IAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment: Mesh Networking [Electronic resource] / IEEE Standards Activities Department.-[USA]: IEEE, 2008.

3. Raniwala A, Gopalan K, Chiueh T. Centralized channel assignment and routing algorithms for multichannel wireless mesh networks. ACM Mobile Computing and Communications Review, 2004, vol. 8, pp. 50-65.

4. Легков К.Е., Федоров А..Е. Беспроводные Mesh-сети специального назначения.// Инфоком-муникационные технологии. № 2 2009. — С. 25-37.