книги / Современные принципы и технологии управления инфокоммуникационными сетями.-1
.pdf5.3.3. Модели данных
Базовая модель данных определена в спецификации TR-106. Модель данных представляет собой дерево объектов. Каждый из объектов может содержать одну или несколько переменных. Доступ к объектам и переменным выполняется в режиме или только для чтения (read-only) или для чтения и записи (read-write). Переменные, доступные для чтения, как правило, содержат общую информацию об устройстве и его состоянии. Переменные, доступные для чтения и записи, используются для описания информации, которая позволяет изменить режим работы устройства.
Спецификация TR-106 требует, что данные должны быть представлены в виде иерархической структуры (дерева объектов). В свойствах объекта указывается, сколько экземпляров этого объекта присутствуют в дереве (минимальное и максимальное количество).
Любое устройство, к которому обращается ACS, будь то шлюз или абонентское оборудование (CPE), должно иметь корневой объект (root). Этот корневой объект должен называться или
«Device» (для CPE) или «InternetGatewayDevice» (для шлюза интернет).
К корневому объекту могут быть подсоединены объекты трех типов:
1. Объекты устройства:
–объекты, специфичные для CPE и использующиеся для корневого объекта типа Device (определены в TR-181);
–объекты, специфичные для шлюза и использующиеся для корневого объекта типа InternetGatewayDevice (определены
вTR-098).
2.Компоненты (Components), определенные в спецификациях TR-143, TR-157. Компоненты содержат объекты, описывающие общие параметры и характеристики устройств – использование вычислительных ресурсов, настройки сети и т.п.
3.Объект сервисы (Services), в который включаются все объекты, характеризующие соответствующие сервисы, реализуемые устройством.
181
5.3.3.1. Объекты устройств
Объекты абонентского устройства типа Device (TR-181).
Параметр DeviceSummary (использовался в ранних версиях модели данных) позволяет серверу ACS получить интегрированную информацию об устройстве. Параметр представляет собой список имен объектов, начиная с имени корневого объекта, и следующих за ним сервисных объектов, с указанием для каждого объекта версии и числа экземпляров этого объекта.
Спецификация TR-181 использует понятия интерфейсов. Каждый интерфейс моделирует параметры соответствующего уровня модели OSI, реализуемого данным устройством. Объект, описывающий интерфейс, должен содержать набор базовых параметров интерфейса. Набор включает в себя следующие переменные:
Enable – административное состояние интерфейса (используется тип данных boolean, поэтому может быть в двух состояниях – true (соответствует включенному интерфейсу) и false (интерфейс выключен)).
Status – оперативное состояние интерфейса (определены состояния Up, Down, Unknown, Dormant, NotPresent, LowerLayerDown, Error).
Alias – альтернативное имя, используемое для идентификации интерфейса.
Name – текстовое имя, используемое для идентификации интерфейса.
LastChange – время в секундах, с момента последнего изменения состояния интерфейса.
LowerLayers – ссылки на интерфейсные объекты, которые моделируют параметры нижележащих уровней.
С объектом, описывающим интерфейс, может быть связан объект с данными статистики (Stats). Объект Stats содержит переменные со счетчиками посланных и переданных: байтов, пакетов, пакетов с ошибками, пакетов с широковещательными, групповыми и уникальными адресами, отклоненных пакетов и пакетов с неизвестным протоколом.
182
Также допускается, что производитель оборудования может включать дополнительные объекты для более полного описания своего устройства. В этом случае объект производителя оборудования должен иметь следующее имя:
X_<VENDOR>_VendorSpecificName,
где <VENDOR> – уникальный идентификатор производителя (доменное имя или OUI – организационно уникальный идентификатор, выдаваемый IEEE),
VendorSpecificName – имя объекта, включаемого производителем в модель данных.
Объекты устройства типа InternetGatewayDevice (TR-098)
содержат следующую информацию, описывающую шлюз:
– общая информация об устройстве (DeviceSummary и DeviceInfo): информация о производителе, серийном номере, версиях аппаратного и программного обеспечения, данные о конфигурационных файлах;
–данные об устройствах, подсоединенных к шлюзу;
–настройки времени шлюза (адрес сервера времени и параметры синхронизации);
–настройки пользовательского интерфейса;
–настройки маршрутизации для WAN и LAN интерфейсов (IP-адреса, таблицы маршрутов и т.п.);
–настройки виртуальной сети;
–параметры обработки очереди пакетов;
–настройки диагностических тестов;
–настройки интерфейса WiFi;
–настройки интерфейса DSL и т.д.
5.3.3.2. Компоненты
Объекты Components, определенные в TR-157, могут быть использованы для описания как абонентского устройства CPE, так и шлюза. Объекты компонентов содержат следующие параметры:
– информация об устройстве (DeviceInfo): статус памяти (размер общей/свободной), статус запущенных процессов (список
183
процессов, идентификаторы, использование процессора и т.п.), данные от датчика температуры, параметры сети (размер окна
иреализация TCP),
–данные сервера ACS, с которого выполняется управление устройством (ManagementServer),
–настройки пользовательского интерфейса для удаленного доступа (UserInterface),
–параметры пользователя (Users),
–параметры устройств, поддерживающих набор протоколов
UPnP (Universal Plug and Play) и DLNA (Digital Living Network Alliance),
–параметры USB,
–настройки защитного экрана (Firewall),
–периодическисобираемуюстатистику(PeriodicStatistics) ит.п. Ниже приведены структуры данных для абонентского уст-
ройства с функцией голосовой передачи VoIP и шлюза интернет с функцией сетевого хранилища данных.
Device
DeviceSummary
DeviceInfo
ManagementServer
Time
UserInterface
Services
VoiceServiceNumberOfEntries = 1
VoiceService.1
VoiceServiceSpecificObjects
InternetGatewayDevice
DeviceSummary
DeviceInfo
ManagementServer
Time
UserInterface
184
Layer3Forwarding
LANDeviceNumberOfEntries = 1
LANDevice.1
WANDeviceNumberOfEntries = 1
WANDevice.1
Services
StorageServiceNumberOfEntries = 1
StorageService.1
StorageServiceSpecificObjects
Пример значения параметра DeviceSummary
Для устройства CPE с поддержкой технологии VoIP: “Device: 1.0[](Baseline: 1), VoiceService: 1.0[1](Baseline: 1)”
Для шлюза Internet Gateway Device, который поддерживает сервис хранения данных:
“InternetGatewayDevice: 1.0[](Baseline: 1), StorageService: 1.0[1](Baseline: 1)”
Типы объектов и компоненты с указанием спецификаций, в которыхописываютсяэтимоделиданных, представленынарис. 5.12.
Поскольку протокол CWMP ориентирован на работу в сетях с большим количеством оборудования, то для реализации массовых операций над множеством сетевых элементов в модели данных было введено понятие профиля. Под профилем понимают набор требований, которым должен удовлетворять объект (или набор параметров) абонентского оборудования CPE. Параметры абонентского оборудования, такие как конфигурация сервиса, его активация, могут быть собраны в один профиль. Профилей может быть один или несколько. При этом становится возможным выполнять действия над множеством сетевых элементов имеющих соответствующий профиль. Как правило, определяют один основной профиль, содержащий базовые настройки оборудования, и несколько дополнительных, описывающих отдельные режимы работы устройства.
185
Рис. 5.12. Структура спецификаций, определяющих модели данных и объекты компонентов протокола CWMP
Объекты и параметры модели данных передаются между абонентским оборудованием CPE и сервером автоконфигураций ACS в виде структур, описанных на расширяемом языке разметки
(eXtensible Markup Language – XML).
Ниже представлено описание фрагмента объекта DeviceInfo: <object name="DeviceInfo." access="readOnly" minEntries="1"
maxEntries="1">
<description>This object contains general device information. </description>
<parameter name="Manufacturer" access="readOnly"> </parameter>
<parameter name="ManufacturerOUI" access="readOnly"> </parameter>
<parameter name="ModelName" access="readOnly" activeNotify="canDeny"></parameter>
<parameter name="Description" access="readOnly" activeNotify="canDeny"></parameter>
<parameter name="ProductClass" access="readOnly"> </parameter>
186
<parameter name="SerialNumber" access="readOnly"> </parameter>
<parameter name="HardwareVersion" access="readOnly" forcedInform="true"></parameter>
<parameter name="SoftwareVersion" access="readOnly" forcedInform="true"></parameter>
….
<parameter name="DeviceLog" access="readOnly" activeNotify="canDeny"></parameter>
</object>
5.3.4. Управление модулями программного обеспечения
Абонентское оборудование городских сетей становится все более сложным и включает в себя множество различного программного обеспечения: встроенное ПО (firmware), операционные системы, среды для кросс-платформенного ПО, прикладное ПО, файлы настроек и т.п. Все это многообразие необходимо обновлять при появлении новых версий, а также устанавливать новые программы или удалять старые, использование которых следует прекратить. Спецификации протокола CWMP используют подход управления модулями программного обеспечения абонентского оборудования CPE (спецификация TR-157).
Модулем ПО называется любой программный элемент, кроме встроенного ПО (firmware), который может быть установлен на абонентское оборудование CPE. Встроенное ПО является отдельным элементом.
Программные модули существуют, по терминологии спецификации TR-157, в исполняемом окружении (Execution Environment – EE) – программной среде, в которой выполняются программы. Примерами таких сред могут служить операционные системы Linux, Android,.NET, OSGi, Java ME. Программные мо-
дули делятся на два типа: модули развертывания и исполняемые модули. Модули развертывания могут содержать ресурсы, такие как функциональные исполняемые модули, конфигурационные
187
файлы или другие ресурсы. Модуль развертывания может быть установлен, обновлен или удален. Исполняемый модуль – это модуль, развернутый из модуля развертывания и представляющий собой службу, сценарий, библиотеку или другой компонент ПО. Исполняемый модуль может быть запущен или остановлен.
Система управления модулями ПО выполняет контроль состояния модулей развертывания (установлен, обновлен или удален), а также исполняемых модулей (запущен, активен, простаивает или остановлен). Управление модулями развертывания со стороны ACS выполняется методом RPC ChangeDUState протокола CWMP. Состояния исполняемых модулей отражаются в значениях соответствующих параметров модели данных устройства и доступны для чтения и записи (например, параметр
SoftwareModules.ExecutionUnit.{i}.RequestedState).
5.3.5. Протокол CWMP
Протокол CWMP является протоколом прикладного уровня. Стек протоколов, используемых CWMP, представлен нарис. 5.13.
Управляющее приложение CPE или ACS – приложение, запускаемое на CPE или ACS и использующее функции CWMP. Приложение может представлять собой сервисы, приложения с графическим интерфейсом и т.п.
Рис. 5.13. Стек протоколов CWMP
188
RPC – набор методов вызова удаленных процедур (Remote Procedure Call – RPC), используемых при взаимодействии между ACS и CPE, который описан в спецификации CWMP.
SOAP – простой протокол доступа к объектам (Simple Object Access Protocol – SOAP). Все сообщения, передаваемые между ACS и CPE, конвертируются в формат XML и передаются по протоколу SOAP. Передача данных в формате XML обеспечивает платформонезависимость реализации управляющих приложений ACS иCPE.
HTTP – протокол передачи гипертекста, выполняет роль транспортного протокола для передачи запросов SOAP. Предполагается, что в большинстве случаев настройки межсетевых экранов разрешают передачу трафика http, соответственно при внедрении CWMP не потребуется существенного пересмотра корпоративных политик информационной безопасности.
TLS – протокол безопасности транспортного уровня
(Transport Layer Security – TLS), используется для обеспечения безопасности передачи данных между CPE и ACS. Используется процедура аутентификации с применением сертификатов.
TCP/IP – протокол для обеспечения гарантированной доставки сообщений между ACS и CPE.
5.3.5.1. Команды протокола CWMP
Команд в традиционном понимании этого механизма в протоколе CWMP нет. Вместо команд для реализации взаимодействия между CPE и ACS протокол CWMP использует механизм удаленного вызова процедур (Remote Procedure Call – RPC).
Функциональность CPE и ACS отличается количеством поддерживаемых методов (процедур). В спецификации TR-069 определены базовые (обязательные к реализации) и опциональные методы, а также предусмотрен механизм создания дополнительных методов, которые могут бытьреализованыпроизводителями оборудования.
Общим и для CPE, и для ACS методом является метод GetRPCMethods. Этот метод может быть использован для получения списка RPC, которые поддерживаются оборудованием CPE
или ACS.
189
Методы, поддерживаемые CPE и ACS, приведены в табл. 5.3
и 5.4.
Таблица 5.3
Методы RPC, поддерживаемые CPE
Метод |
Описание |
|
1 |
2 |
|
|
Базовые методы |
|
SetParameterValues |
Метод может быть использован ACS для измене- |
|
ния одного или нескольких параметров CPE |
||
GetParameterValues |
Метод может быть использован ACS для получе- |
|
ния одного или нескольких параметров CPE |
||
GetParameterNames |
Метод может быть использован ACS для получения |
|
|
спискапараметров, доступныхнаконкретномCPE |
|
SetParameterAttributes |
Метод может быть использован ACS для изменения |
|
|
атрибутоводногоилинесколькихпараметровCPE |
|
GetParameterAttributes |
Метод может быть использован ACS для получения |
|
|
атрибутоводногоилинесколькихпараметровCPE |
|
AddObject |
МетодможетбытьиспользованACS длясозданияново- |
|
гоэкземпляравобъектесмножествомэкземпляров |
||
|
||
DeleteObject |
Методиспользуетсядляудаленияэкземпляраобъекта |
|
Download |
Метод может быть использован ACS для того, чтобы |
|
заставитьзагрузитьфайлизуказанногоисточника |
||
|
||
|
Метод заставляет CPE выполнить перезагрузку. |
|
Reboot |
CPE должен подтвердить в ответе на этот метод |
|
|
и завершить сессию до выполнения перезагрузки |
|
|
Опциональные методы |
|
|
Метод может быть использован ACS для просьбы |
|
ScheduleInform |
CPE запланировать однократное выполнение мето- |
|
|
да Inform в будущем |
|
|
Метод может быть использован ACS для того, что- |
|
Upload |
бы заставить CPE выполнить передачу файла по |
|
|
указанному адресу |
|
|
Метод заставляет CPE выполнить сброс до началь- |
|
FactoryReset |
ных заводских установок. CPE должен выполнить |
|
|
сброс только после корректного завершения сессии |
|
|
Метод может быть использован ACS для определе- |
|
|
ния статуса очередей всех загрузок файлов (ранее |
|
GetAllQueuedTransfers |
запрошенные методами Download или Upload), |
|
|
включая и загрузки, выполняемые из других ис- |
|
|
точников, так называемые AutonomousTransfer |
190