Этот документ (перевод tr-069-1-0-0.pdf [1]) описывает протокол управления клиентскими сетевыми устройствами, так называемый протокол CWMP (CPE WAN Management Protocol), предназначенный для коммуникации между управляемыми устройствами (CPE) и сервером автоматизированной конфигурации (Auto-Configuration Server, ACS). Протокол CWMP определяет механизм, который включает в себя защищенную автоматическую конфигурацию CPE, а также включает другие функции управления CPE в общей структуре обслуживания сетевых устройств.

Примечание: объяснение незнакомых терминов и сокращений см. в разделе "1.6. Терминология".

[1.1. Функциональные компоненты]

CWMP предназначен для поддержки различных функциональных возможностей, предназначенных для управления коллекцией CPE, и включает в себя следующие основные возможности:

• Автоматическая конфигурация и динамическое предоставление служб.
• Управление обновлением ПО или образами firmware.
• Мониторинг статуса и производительности.
• Диагностика.

1.1.1. Автоматическая конфигурация и динамическое предоставление служб. Протокол управления глобальной сетью CWMP позволяет серверу ACS конфигурировать CPE или набор CPE на основе различных критериев. Механизм конфигурирования включает определенные параметры конфигурирования и общий механизм добавления возможностей конфигурирования, определяемых поставщиком, по мере необходимости.

Механизм конфигурирования позволяет выполнять конфигурирование CPE во время начального подключения к сети широкополосного доступа, а также возможность повторного конфигурирования в любое последующее время. Это включает поддержку асинхронного инициированного ACS повторного конфигурирования CPE.

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

Протокол также предоставляет дополнительные инструменты для управления специфичными для CPE компонентами дополнительных приложений или служб, для которых требуется дополнительный уровень безопасности для управления, например, те, которые связаны с платежами. Механизм контроля таких опций с использованием Voucher с цифровой подписью определен в Приложении C.

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

1.1.2. Управление обновлением ПО или образами firmware. CWMP предоставляет инструментарий для управления загрузками файлов образа и программного обеспечения CPE. Протокол предоставляет механизмы для идентификации версии, инициирования загрузки файла (загрузка может быть инициирована со стороны ACS, а также со стороны CPE), и оповещения сервера ACS о статусе загрузки файла - была ли она успешной или неудачной.

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

1.1.3. Мониторинг статуса и производительности. CWMP обеспечивает поддержку CPE для предоставления информации, которую ACS может использовать для контроля состояния и статистики производительности CPE. Протокол определяет общий набор таких параметров и предоставляет стандартный синтаксис для поставщиков, чтобы определить дополнительные нестандартные параметры, которые ACS может контролировать. Он также определяет набор условий, при которых CPE должен активно уведомлять ACS об изменениях.

1.1.4. Диагностика. CWMP обеспечивает поддержку CPE для предоставления информации, которую ACS может использовать для диагностики соединений или проблем с обслуживанием. Протокол определяет общий набор таких параметров и общий механизм добавления специфических для производителя диагностических возможностей.

1.1.5. Управление идентификацией для веб-приложений. Для поддержки веб-приложений для доступа из браузера в локальной сети CPE протокол управления CWMP определяет дополнительный механизм, который позволяет таким веб-сайтам настраивать свой контент с явным знанием связанного CPE. Этот механизм описан в Приложении D.

[1.2. Позиционирование в архитектуре автоматического конфигурирования]

TR-046 [2] описывает фреймворк для автоматического конфигурирования устройств B-NT. Этот процесс состоит из трех последовательных стадий, каждая из которых фокусируется на определенном аспекте общего процесса автоматической конфигурации B-NT.

Процедуры для первых двух шагов автоконфигурации B-NT описаны в TR-062 [3] и TR-044 [4]. Они определяют слои процедур ATM и IP соответственно, что используется для инициирования базового широкополосного соединения.

Третья стадия автоматической конфигурации, описанная в TR-046, определяет "автоматически настраиваемые комплексные службы" (auto-configured complex services). В случае B-NT протокол CWMP относится главным образом к этой третьей стадии. В частности CWMP предлагается в качестве протокола, используемого в интерфейсе ACS-Southbound между сервером автоматического конфигурирования (ACS) и B-NT, как показано на рисунке 1.

Рис. 1. Позиционирование в архитектуре автоматического конфигурирования (1).

Примечание (1): в случае B-NT, в отличие от вложенной модели TR-046, этот протокол также позволяет конфигурировать параметры уровня ATM, если альтернативный протокол автоматического конфигурирования не используется, например, как определено в TR-062. Однако, если используется альтернатива, то конфигурирование параметров уровня ATM этим протоколом деактивируется.

В дополнение к конфигурированию протокол обеспечивает средства извлечения диагностических данных и данных контроля функционирования из уровня ATM и DSL-модема. Опять же, это противоречит вложенной модели, описанной в TR-046, но обеспечивает альтернативные средства доступа к информации, которая уже может быть получена через существующие протоколы управления, то есть ILMI и EOC линии DSL. Предоставление более продвинутых функций диагностики и мониторинга производительности через этот протокол является предметом дальнейшего изучения.

Хотя протокол CWMP предназначен для управления B-NT, этот протокол также может использоваться для управления другими типами CPE, включая автономные маршрутизаторы и клиентские устройства на стороне LAN, что также показано на рисунке 1. Если не указано иное, то протокол CWMP, как определено в настоящей спецификации, применяется к любому такому управляемому устройству. Части этого описания, которые применяются только к B-NT, явно указаны в тексте. Данная спецификация включает полное определение модели параметров CPE для B-NT. Соответствующая модель параметров для других конкретных типов устройств выходит за рамки данной спецификации.

[1.3. Обеспечение безопасности]

Протокол CWMP разработан с учетом предоставления высокой степени защищенности. Используемая модель безопасности также поддерживает расширяемость. Он предназначена для обеспечения базовой безопасности для менее надежных реализаций CPE, обеспечивая при этом большую безопасность для тех, кто может поддерживать более продвинутые механизмы безопасности. В общих чертах цели безопасности CWMP следующие:

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

[1.4. Архитектурные особенности]

Протокол CWMP предназначен для предоставления гибкой поддержки различных бизнес-моделей в распространении и обслуживании CPE, включая:

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

Протокол предназначен для обеспечения гибкости в модели связности сторон обмена:

• Позволяет обоим сторонам CPE и ACS инициировать установку соединения, избегая необходимости поддерживать постоянное соединение между каждым CPE и ACS.
• Функциональные взаимодействия между ACS и CPE не должны зависеть от того, какой конец инициировал установление соединения. В частности, даже там, где инициированная ACS связность не поддерживается, все инициированные ACS транзакции должны иметь возможность иметь место через соединение, инициированное CPE.
• Разрешить одному или нескольким серверам ACS обслуживать совокупность CPE, которая может быть связана с одним или несколькими поставщиками услуг.
• Оптимизируется использование установленных соединений, чтобы свести к минимуму накладные расходы на соединение, позволяя выполнять несколько двунаправленных транзакций через одно соединение.

Протокол предназначен для поддержки обнаружения и объединения ACS и CPE:

• Для CPE предоставляются механизмы обнаружения подходящего ACS для данного поставщика услуг.

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

Модель протокола CWMP позволяет серверу ACS управлять и контролировать различные параметры, связанные с CPE. Механизмы, предусмотренные для доступа к этим параметрам, проектируются со следующими предпосылками:

• Различные CPE могут иметь различные уровни возможностей, реализуя различные подмножества необязательных функций. В результате ACS должен иметь возможность обнаруживать возможности конкретного CPE.

• ACS должен иметь возможность управлять текущей конфигурацией CPE и контролировать её.

• Другие объекты управления, кроме ACS, могут быть способны управлять некоторыми параметрами конфигурации CPE (например, посредством автоматического конфигурирования на стороне LAN). В результате протокол должен позволять ACS учитывать внешние изменения в конфигурации CPE. ACS также должен иметь возможность контролировать, какие параметры конфигурации могут управляться средствами, отличными от ACS.

• Протокол должен обеспечить управление параметрами, специфичными для вендора. Эти параметры должны определяться с обеспечением и к ним доступа.

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

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

[1.5. Допущения]

В описании протокола CWMP сделаны следующие допущения:

• В случае устройства B-NT перед использованием протокола CWM сначала выполняется начальная автоконфигурация B-NT, как это определено в TR-062 [3] и TR-044 [4], и устанавливается соединение с WAN, в которой становится доступным ACS.
• Все устройства CPE независимо от из типа (мост(2), роутер или другое сетевое оборудование) получают IP-адрес, чтобы можно было организовать взаимодействие с ACS.
• CPE может взаимодействовать с одним ACS одновременно. В любой момент времени CPE известно только об одном ACS, с которым он может соединяться. ACS может передать CPE другому ACS только путем явного изменения контактной и аутентификационной информации ACS. Замечание: коллекция серверов ACS, расположенная внутри области сервиса балансировки сетевой нагрузки, в этом документе считается единственным сервером ACS.

Примечание (2): в случае сетевого моста (bridge) CPE должен установить коннект на слое IP специально для коммуникаций управления. Механизм получения этого коннекта зависит от специфики архитектуры сети. Например может соединиться, используя IPoE с выделением адреса по DHCP, или может соединиться, используя PPPoE.

[1.6. Терминология]

В документах, описывающих протокол CWMP, используются следующие аббревиатуры и термины.

ACS Auto-Configuration Server, командный сервер. Компонент broadband-сети, отвечающий за автоконфигурацию CPE устройств.

ATM Asynchronous Transfer Mode, телекоммуникационный стандарт описания низкоуровневого протокола, предназначенный для цифровой передачи нескольких типов сетевого трафика. Он может обрабатывать традиционный трафик данных в реальном времени, с гарантированными низкими задержками, что используется для передачи данных звука и видео. ATM предоставляет функционал переключения маршрутов и пакетов с использованием временного мультиплексирования (time-division multiplexing, TDM).

B-NT Broadband Network Termination, относится к CPE-устройству с поддержкой broadband-доступа, управляемому через ACS.

BRAS Broadband Remote Access Server.

BSP Broadband Service Provider, сервис-провайдер широкополосной услуги связи.

CA Certificate Autority, доверенный сервер проверки и выдачи сертификатов.

CMTS Cable Modem Termination System.

CPE Customer Premise Equipment, управляемое абонентское оборудование.

CWMP CPE WAN Management Protocol.

DSLAM Digital Subscriber Line Access Multiplexer — мультиплексор (модем) доступа цифровой абонентской линии xDSL.

DT Device Type Schema.

IP Internet Protocol.

IPDR Internet Protocol Detail Record. В технологиях телекоммуникаций IP Detail Record (IPDR) предоставляет основанную на IP службу, которая может использоваться системами поддержки операций (OSS) системами поддержки бизнеса (BSS). Содержимое IPDR определяется провайдером сервиса, вендором сети/службы, или любым другим сообществом пользователей с авторизацией для указания определенных основанных на IP служб в указанном контексте. Спецификации IPDR изначально были разработаны организацией Internet Protocol Detail Record, Inc. (aka IPDR.org). В 2007 году организация IPDR.org была взята под контроль TM Forum, индустриальной ассоциацией более чем 900 глобальных пользователей из 160 стран, относящихся к телекоммуникациям, кабельному оборудованию, медиа и Интернету. Спецификации IPDR включают требования для IPDR коллекции, протоколам кодирования и обмена записями IPDR, руководства по дизайну службы IPDR и т. д.

IPDRDoc IPDR Document.

IR IPDR Recorder.

IS IPDR Store.

IT IPDR Transmitter.

Option опция, фича CPE, которая может быть разрешена или запрещена с помощью подписанного ваучера (Voucher).

OUI Organizationally Unique Identifier.

RPC Remote procedure call.

SE Service Element.

SOAP Simple Object Access Protocol, протокол доступа к объектам - протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур.

TR Technical Report.

TR-111 вводит дополнительные тесты прохождения трафика NAT и сетевого обмена non-IP.

TR-143 Спецификация TR-143, определенная Broadband Forum, помогает операторам определить, находится ли проблема в сети оператора или в домашней сети клиента. TR-143 предоставляет руководства для активного мониторинга и диагностики клиентского оборудования. Официально это называется "Enabling Network Throughput Performance Tests and Statistical Monitoring", что включает тесты, запускаемые на конечной точке TR-069. В контексте TR-143 активный мониторинг позволяет измерить метрики производительности, важные для гарантии параметров бизнеса, соответствующих клиентскому договору (Service Level Agreements, SLAs). Тесты подразумевают активную передачу и прием данных через управляемую экосистему, с поддержкой инициируемых диагностик как со стороны сети, так и со стороны оборудования CPE. Ключевое достоинство активного мониторинга - возможность определения производительности путей службы или сегментов пути, в зависимости от того, к какому сегменту сети осуществляется доступ.

TR-181 Расширение стандарта TR-069. Мощный стандарт нового поколения TR-069: TR-181 i2.

TR-232 Bulk Data Collection. Представляет основанный на IPDR механизм, позволяющий провайдерам сервисов эффективно собирать на регулярной основе потенциально большое количество данных из их популяции CPE. Этот механизм сбора данных построен поверх стандарта IPDR, как это определено в форуме TM, вместо стандарта CWMP, как это определено TR-069, поскольку CWMP разработан для протокола управления устройствами вместо протокола сбора данных. Таким образом, использование IPDR вместо системы управления CWMP не подвержено вмешательствам и передача данных происходит более эффективно. Устройства, поддерживающие механизм сбора bulk-данных на основе IPDR будут иметь механизм, конфигурируемый через CWMP.

Voucher ваучер, снабженная цифровой подписью структура данных, которая инструктирует определенное CPE разрешить или запретить опцию (Option), и характеристики, определяющие, при каких условиях сохраняются параметры.

WAN Wide Area Network.

WG Working Group.

XMPP Extensible Messaging and Presence Protocol (XMPP): Core, IETF, 2011 (RFC 6120 https://www.rfc-editor.org/rfc/rfc6120).

[2.1. Архитектура: компоненты протокола]

Протокол CWMP состоит из нескольких уникальных для него компонентов, и также он используется несколько стандартных протоколов, см. рис. 2. Краткое описание каждого слоя приведено в таблице 1.

Рис. 2. Стек протоколов, используемый CWMP.

Таблица 1. Слои протоколов, используемые в CWMP.

[2.2. Механизмы безопасности]

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

В протокол встроены следующие механизмы безопасности:

• Протокол для транспорта коммуникаций между CPE и ACS поддерживает использование SSL/TLS. Это обеспечивает конфиденциальность транзакций, целостности данных, и позволяет реализовать аутентификацию между CPE и ACS на основе сертификатов.
• Слой HTTP обеспечивает альтернативные средства аутентификации CPE на основе совместно используемых секретов.

Протокол включает дополнительные механизмы безопасности, связанные с опциональным Voucher-механизмом с цифровой подписью и Signed Package Format, описанными в Приложении C и Приложении E соответственно.

2.2.1. Инициализационные модели безопасности. Инициализация механизмов безопасности описана в контексте различных бизнес-моделей для распространения CPE. Рассматриваются три модели:

• Распространение устройств CPE сервис-провайдером, связанным с ACS.
• Распространение CPE ритейлом (розничной сетью продаж), когда связь с сервис-провайдером и пользователем устанавливается в момент покупки.
• Распространение CPE ритейлом без предварительной связи с функционалом CPE.

В первых двух случаях специальный идентификатор CPE может быть заранее известен для ACS перед первым использованием CPE. В этих случаях могут использоваться следующие механизмы:

В последнем случае, когда CPE распространяются "чистыми" в контексте использования модели безопасности, нет возможности обеспечить предварительную взаимосвязь CPE с определенным ACS. В следующей таблице представлены возможные подходы к решению этой проблемы, но не предпринимается попытка предписать конкретный подход:

[2.3. Компоненты архитектуры]

2.3.1. Параметры. Спецификация метода RPC (см. Приложение A [16]) определяет традиционный механизм, по которому ACS может читать или записывать параметры (Parameters), чтобы конфигурировать CPE, а также отслеживать состояние CPE и его статистику. Специфический для роутера Интернет (Internet Gateway Device) список параметров приведен в Приложении B.

Каждый Parameter состоит из пары имя-значение (name-value). Имя идентифицирует определенный параметр, и оно имеет иерархическую структуру, подобно файлам и директориям. Отдельные уровни в иерархии разделяются символом точки '.'. Значение Parameter может быть одним из нескольких определенных типов данных (см. Приложение B).

Параметры могут быть определены с доступом только для чтения (read-only) или для чтения и записи (read-write). Read-only параметры могут использоваться, чтобы позволить ACS определить специфические характеристики устройства CPE, наблюдать его текущее состояние, или собирать статистику использования. Записываемые параметры позволяют для ACS настраивать различные аспекты функционирования CPE. Все записываемые параметры также должны быть читаемыми. Значение некоторых записываемых параметров могут быть независимо модифицируемыми через другие способы взаимодействия, не относящиеся к этой спецификации (например, некоторые параметры могут быть также модифицированы через LAN в процессе протокола автоматической конфигурации сетевого доступа).

Протокол CWMP поддерживает механизм обнаружения, позволяющий для ACS определить, какие параметры поддерживает определенный CPE, позволяя определять как опциональные параметры, так и поддержку прямого добавления параметров, которые в будущем будут введены в стандарт.

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

2.3.2. Передачи файла. Спецификация метода RPC (см. Приложение A [16]) определяет механизм, упрощающий загрузки файла или (опционально) выгрузки файла для различных целей, таких как обновления firmware или файлов конфигурации, специфичных для вендора.

Когда передача инициируется ACS, для CPE предоставляется место расположения передаваемого файла с использованием транспортного протокола HTTP, или опционально протоколов HTTPS, FTP или TFTP. Затем CPE выполняет передачу файла и оповещает ACS об успехе или неудаче этой операции.

Загрузки могут быть опционально инициированы CPE. В этом случае CPE сначала запрашивает у ACS определенный тип файла. Затем ACS может ответить инициированием загрузки по тем же шагам, которые использовались при загрузке, инициированной стороной ACS.

Протокол CWMP также определяет формат файла с цифровой подписью (digitally signed file format), который опционально может использоваться для загрузок. Этот Signed Package Format описан в Приложении E.

2.3.3. Оповещения, инициируемые CPE. Спецификация метода RPC (см. Приложение A [16]) определяет механизм, который позволяет CPE оповестить соответствующий ACS об различных событиях, с гарантированием обмена CPE-ACS с определенной минимальной частотой.

Это включает механизмы для установки коммуникации при начальной инсталляции CPE, чтобы залить (bootstrap) начальные настроечные параметры в CPE. Это также включает механизм установки периодической коммуникации с ACS на постоянной основе или при возникновении событий, о которых должен быть предоставлен отчет для ACS (таких как изменение broadband IP адреса CPE). ACS должен быть оповещен об этом событии, чтобы сохранить возможность получения входящих соединений для CPE.

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

2.3.4. Асинхронные оповещения, инициируемые ACS. Важным аспектом службы автоматического конфигурирования является возможность для ACS асинхронного уведомления CPE об изменении конфигурации. Это позволяет использовать механизм автоматического конфигурирования для услуг, требующих перенастройки CPE почти в реальном времени. Например, это может быть использовано для предоставления конечному пользователю немедленного доступа к услуге или функции, на которую он подписался, без ожидания следующего периодического интервала информирования.

Протокол CWMP включает в себя механизм для ACS, чтобы он мог выдать запрос на соединение с CPE в любое время, инструктируя его установить сеанс связи с ACS. Хотя протокол CWMP также позволяет CPE опрашивать ACS вместо использования инициированных ACS соединений, CWMP не полагается на опрашивание или установление постоянных соединений из CPE для обеспечения асинхронного уведомления.

[3.1. Процедуры и требования: обнаружение ACS]

Протокол CWMP определяет следующие механизмы, которые может использовать CPE обнаружения адреса связанного с ним ACS:

1. CPE может быть сконфигурирован локально с указанием URL его ACS. Например, это может быть осуществлено через LAN-протокол автоматической конфигурации сетевого интерфейса CPE. CPE мог бы использовать DNS для разрешения в IP доменного имени ACS из его URL.

2. Как часть автоматической конфигурации слоя IP, сервер DHCP при доступе к сети может быть сконфигурирован так, чтобы в его DHCP-опциях присутствовал ACS URL [12]. Тогда CPE, зная доменное имя из URL, мог бы использовать DNS для разрешения IP-адреса ACS. В этом случае вторая опция DHCP МОЖЕТ быть использована для установки кода конфигурирования ProvisioningCode, который может использоваться для указания основного поставщика услуг и другой информации конфигурирования для ACS.

CPE идентифицирует себя для сервера DHCP как поддерживающий этот метод, включая строку "dslforum.org" (все строчные буквы) в любом месте идентификатора класса поставщика (Vendor Class Identifier, опция 60 DHCP).

CPE МОЖЕТ использовать значения, полученные от DHCP-сервера в специфичной для поставщика информации (Vendor Specific Information, опция 43 DHCP), для установки соответствующих параметров, перечисленных в таблице 2. Эта опция DHCP закодирована как список одного или нескольких инкапсулированных параметров поставщика в формате, определенном в [12]. Этот список может включать другие специфичные для поставщика параметры в дополнение тем, что здесь перечислены.

Таблица 2. Встроенные опции, специфичные для поставщика (Encapsulated Vendor Specific Options).

Примечание (3): как это определено для роутера (Internet Gateway Device).

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

ACS URL ДОЛЖЕН быть в корректной форме HTTP или HTTPS URL [5]. Использования HTTPS URL показывает, что ACS поддерживает SSL. Если предоставлен HTTPS URL, и CPE не поддерживает SSL, то он МОЖЕТ попытаться использовать HTTP подразумевая, что остальная часть URL не изменена.

Как только CPE установит соединение с ACS, ACS может в любой момент изменить параметр адреса ACS, сохраненный внутри CPE (InternetGatewayDevice.ManagementServer.URL). После модификации CPE ДОЛЖЕН использовать этот измененный адрес для всех последующих коммуникаций с ACS.

Порция имени хоста ("host") в ACS URL используется в CPE для проверки сертификата из ACS, когда используется аутентификация на основе сертификата. Поскольку это зависит от точности URL-адреса ACS, общая безопасность этого протокола зависит от безопасности URL-адреса ACS.

CPE ДОЛЖЕН ограничить возможность локального конфигурирования ACS URL механизмами, которые требуют строгой безопасности. CPE МОЖЕТ дополнительно ограничить возможность локальной установки ACS URL только лишь начальной настройкой, предотвращая дальнейшую локальную конфигурацию после того, как начальное соединение с ACS было успешно установлено, так что только его существующий ACS может впоследствии изменять этот URL.

Использование DHCP для конфигурирования ACS URL ДОЛЖНО быть ограничено ситуациями, в которых безопасность линка между сервером DHCP и CPE может быть заверено сервис-провайдером. Поскольку в сам DHCP не встроен механизм безопасности, должны быть предусмотрены другие средства обеспечения этой безопасности.

[3.2. Установка соединения]

3.2.1. Инициирование соединения со стороны CPE. CPE может в любой момент времени инициировать соединение с ACS, используя предварительно установленный адрес ACS (см. секцию 3.1). CPE ДОЛЖЕН установить соединение с ACS и выдать RPC-метод Inform (за которыми следуют процедуры, описанные в секции 3.7) при следующих условиях:

• Первоначальное установление соединения CPE, когда он обращается к сети на начальной инсталляции.
• При включении питания или сбросе.
• Однократно с интервалом PeriodicInformInterval (например, каждые 24 часа).
• По указанию дополнительного метода ScheduleInform.
• Всякий раз, когда CPE получает действительный запрос на соединение от ACS (см. секцию 3.2.2).
• Всякий раз, когда меняется URL ACS.
• Всякий раз, когда модифицируется параметр, которые требует инициации отчета об изменении (Inform on change). В случае роутера (Internet Gateway Device) это включает изменение следующего (см. Приложение A.3.3.1 [16]):

- IP-адрес соединения к публичной сети по умолчанию (default broadband connection).
- Управление IP-адресом (связанным с Connection Request URL).
- Код конфигурирования (provisioning code).
- Версия программного обеспечения (Software version).

• Всякий раз, когда значение параметра, помеченного ACS для "активного уведомления" (active notification) с помощью метода SetParameterAttributes, изменяется по внешней причине (причина, отличная от самого ACS). Изменения параметра, которые делает сам ACS через SetParameterValues, НЕ ДОЛЖНЫ приводить к инициации новой сессии. Если параметр модифицируется больше одного раза перед тем, как CPE смог инициировать сессию для выполнения оповещения, то выполняется только одно оповещение.

Если в течение сеанса сессии связи параметр меняется по внешней причине, то это изменение приводит к установке новой сессии после завершения текущей сессии (это НЕ ДОЛЖНО влиять на текущую сессию).

Чтобы избежать генерации чрезмерного трафика с ACS, CPE МОЖЕТ установить локально заданный лимит на частоту оповещений об изменении параметра. Этот лимит ДОЛЖЕН быть определен таким образом, чтобы он превышался только в необычных обстоятельствах. Если этот лимит превышен, то CPE МОЖЕТ задержать локально заданное количество инициирования сессии для оповещения ACS. После истечения этой задержки CPE ДОЛЖЕН инициировать сессию с ACS, и показать все соответствующие изменения параметра (тех параметров, которые были помечен для оповещения), которые произошли с момента последнего такого уведомления.

CPE НЕ ДОЛЖЕН поддерживать открытым соединение с ACS когда на CPE или ACS больше нет ожидающих сообщений.

3.2.2. Инициирование соединения со стороны ACS. ACS в любой момент времени запрашивает у CPE инициацию соединения с ACS, используя механизм оповещения Connection Request. Поддержка этого механизма ТРЕБУЕТСЯ в CPE, и РЕКОМЕНДУЕТСЯ в ACS.

Этот механизм основан на том, что на CPE установлен IP-адрес, который маршрутизируется со стороны ACS. Если CPE находится за сетевым экраном (firewall) или за NAT-устройством, расположенным между ACS и CPE, то ACS никак не сможет обратиться к CPE (конечно, если firewall и NAT не настроены специальным образом). В таком случае возможен только способ инициации соединения со стороны CPE (см. секцию 3.2.1), других вариантов нет.

Механизм оповещения Connection Request определен следующим образом:

• Оповещение Connection Request это HTTP Get на указанный URL, обозначенный стороной CPE. Значение URL доступно как параметр только для чтения (read-only Parameter) на CPE. Путь этого значения URL ДОЛЖЕН случайно генерироваться в CPE, чтобы он был уникальным для каждого CPE.
• Оповещение Connection Request ДОЛЖНО использовать HTTP, не HTTPS. Соответствующий URL ДОЛЖЕН быть типа "http".
• В оповещении Connection Request HTTP Get не передаются никакие данные. Любые данные, которые могут содержаться в нем, ДОЛЖНЫ игнорироваться на CPE.
• CPE ДОЛЖЕН использовать digest-authentication для аутентификации ACS перед продолжением сеанса связи - CPE НЕ ДОЛЖЕН инициировать соединение с ACS из-за запроса, который не прошел аутентификацию. Общий секрет (shared-secret), используемый для аутентификации ACS, доступен как модифицируемый параметр (modifiable Parameter) на CPE.
• CPE ДОЛЖЕН ограничить количество оповещений Connection Request, которое он принимает за определенный период времени, чтобы снизить возможность для атаки типа "отказ в обслуживании" (DoS).
• Успешная аутентификация HTTP Get на обозначенную пару порт/URL приводит к тому, что CPE выполнит фиксированное действие: он установит сессию с заранее определенным адресом ACS (см. секцию 3.1), и как только соединение установлено, CPE отправляет сообщение Inform.
• Если CPE уже находится в установленной сессии с ACS, когда он получил оповещение Connection Request, то он из-за этого НЕ ДОЛЖЕН преждевременно завершать эту сессию.

Этот механизм основан на том, что с ACS уже была как минимум одна предыдущая сессия связи с CPE, когда эта сессия была инициирована со стороны CPE. Во время этого взаимодействия, если ACS хочет разрешить будущие транзакции, инициируемые со стороны ACS, то он прочитает значение параметра InternetGatewayDevice.ManagementServer.ConnectionRequestURL. Если URL, используемый для доступа управления, поменялся, то CPE должен оповестить ACS выдачей сообщения Inform, показывающего новый IP-адрес для управления (management IP address, как это описано в таблице 33), что поддержит информацию ACS в актуальном состоянии.

[3.3. Использование SSL/TLS и TCP]

Использование SSL/TLS для транспорта протокола CWMP РЕКОМЕНДУЕТСЯ, хотя протокол может вместо этого использовать простое прямое соединение TCP. Если SSL/TLS не используется, то будут принесены в жертву некоторые аспекты безопасности. В частности, SSL/TLS обеспечивает конфиденциальность и целостность данных, а также позволяет аутентификацию на основе сертификатов вместо аутентификации на основе общего секрета.

Некоторые ограничения на использование SSL/TLS и TCP определяются следующим образом:

• Если SSL/TLS поддерживается, то НЕОБХОДИМО использовать версии SSL 3.0 [10] или TLS 1.0 [11].
• Если SSL/TLS поддерживается, то ДОЛЖНЫ поддерживаться алгоритмы шифрования с длинами ключа больше или равным 128 бит.
• CPE ДОЛЖЕН быть в состоянии инициировать исходящие соединения в сторону ACS.
• ACS MUST ДОЛЖЕН быть в состоянии принять соединения, инициированные со стороны CPE.
• Если используется SSL/TLS, то CPE ДОЛЖЕН аутентифицировать ACS с использованием сертификата, предоставленного ACS.
• Если используется SSL/TLS, то ACS МОЖЕТ принять проверенный предоставленный CPE сертификат для аутентификации CPE, однако ACS ДОЛЖЕН позволить установку соединения SSL/TLS, если CPE не предоставил сертификат.

[3.4. Использование HTTP]

SOAP-сообщения, передаваемые между CPE и ACS, используют протокол HTTP 1.1 [5], где CPE действует как HTTP-клиент, а ACS действует как HTTP-сервер.

3.4.1. Кодирование SOAP поверх HTTP. Кодирование SOAP поверх транспорта HTTP расширяет базовый HTTP-профиль SOAP, описанный в [8], следующим образом:

• SOAP-запрос от ACS к CPE передается поверх HTTP response, в то время как SOAP response устройства CPE в ответ на ACS посылается через последующий HTTP post.
• Каждый HTTP post или response может содержать больше одного SOAP-конверта (с оговоренными ограничениями). Каждый конверт может содержать SOAP request или response, независимо от любого другого конверта.
• Когда в одиночном HTTP Request содержится больше одного конверта, то заголовок SOAPAction в HTTP Request ДОЛЖЕН быть без значения (без кавычек), показывая тем самым, что этот заголовок не предоставляет никакой информации относительно цели сообщения. Т. е. он должен выглядеть следующим образом:

   SOAPAction:

Сообщение Inform содержит аргумент MaxEnvelopes, который показывает для ACS максимальное количество SOAP-конвертов, которое может содержаться в одном HTTP response. Значение этого параметра может быть 1 или больше. Как только сообщение Inform было получено, любой HTTP response от ACS может включать не более этого количества SOAP-конвертов (request-ов или response-ов).

Сообщение Inform также содержит аргумент MaxEnvelopes, который показывает для CPE максимальное общее количество SOAP-конвертов, которое может содержать один HTTP post. Значение в этом параметре может быть 1 или больше. Как только был принят Inform response, любой HTTP post от CPE может включать не больше этого общего количества SOAP-конвертов (request-ов или response-ов).

В каждом направлении порядок SOAP-конвертов определяется независимо от количества конвертов, переносимых парой HTTP post/response. В частности, конверты упорядочиваются от первого до последнего в пределах одного HTTP post/response, и затем между последующими парами HTTP post/response. Т. е. последовательность конвертов внутри каждого HTTP post/response и затем между последующими post или response можно рассматривать как одну упорядоченную последовательность конвертов.

Чтобы обеспечить правильную взаимосвязь request-ов и response-ов, запрашивающая сторона МОЖЕТ включать тег ID в SOAP-заголовке, который, если используется, ДОЛЖЕН быть возвращен отвечающей стороной с таким же значением. Кодирование этого заголовка описано в секции 3.5.

Ниже показан пример HTTP Response от ACS, содержащий Response на поступивший SOAP Request, который содержит ID Header, и не связанный SOAP Request:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xyz

< soap:Envelope
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
   soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:cwmp="urn:dslforum-org:cwmp-1-0">
      < soap:Header>
         < cwmp:ID soap:mustUnderstand="1">1234< /cwmp:ID>
      < /soap:Header>
      < soap:Body>
         < cwmp:Response1>
            < argument>value< /argument>
         < /cwmp:Response1>
      < /soap:Body>
< /soap:Envelope>

< soap:Envelope
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
   soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:cwmp="urn:dslforum-org:cwmp-1-0">
      < soap:Body>
         < cwmp:Request2>
            < argument>value< /argument>
         < /cwmp:Request2>
      < /soap:Body>
< /soap:Envelope>

3.4.2. Сессии транзакции. Для выполнения последовательности транзакций, формирующих одну сессию, устройство CPE ДОЛЖНО поддерживать TCP-соединение, которое сохраняется постоянным в течение продолжительности сессии.

Чтобы приспособиться к ситуациям, когда поддержка непрерывного TCP невозможна (например, когда работа осуществляется через HTTP 1.0 proxy), ACS ДОЛЖЕН использовать cookie сессии, чтобы поддерживать состояние сессии, как это описано в [7]. ACS ДОЛЖЕН использовать только те cookie, которые помечены для Discard, и НЕ ДОЛЖЕН подразумевать, что CPE будет сохранять cookie в течение продолжительности сессии.

Чтобы гарантировать, что ACS может использовать cookie сессии, CPE ДОЛЖЕН поддерживать cookie, как описано в [7], включая возврат значения cookie в каждом последующем HTTP post, за исключением того, что CPE не должен поддерживать хранилище cookie после завершения сессии.

Когда транзакция сессии завершена, CPE ДОЛЖЕН завершить соответствующее соединение TCP с ACS, и отбросить все cookie, помеченные для Discard.

3.4.3. Файловые транзакции. Если CPE был проинструктирован выполнить передачу файла запросом Download или Upload от ACS, и если место размещения файла указано как HTTP URL с тем же именем хоста, что и у ACS, то CPE МОЖЕТ выбрать любой из следующих методов для выполнения передачи файла:

• CPE МОЖЕТ послать HTTP get/post на уже существующем соединении. Как только файл был передан, CPE МОЖЕТ затем перейти к отправке дополнительных сообщений в ACS, продолжая поддерживать соединение.
• CPE МОЖЕТ открыть второе соединение, поверх которого будет передаваться файл, поддерживая сессию с ACS, по которой он может продолжать посылать сообщения.
• CPE МОЖЕТ завершить сессию с ACS, и затем совершить передачу файла.

Если место размещения файла не HTTP URL, или это не тот же самый домен, что у ACS, то тогда доступны только два последних варианта.

3.4.4. Аутентификация. Если CPE не был аутентифицирован с помощью SSL/TLS, то ACS ДОЛЖЕН аутентифицировать CPE, используя HTTP. Если для шифрования используется SSL/TLS, то ACS МОЖЕТ использовать либо базовую (basic) аутентификацию, либо аутентификацию с цифровой подписью (digest authentication) [6]. Если SSL/TLS не используется, то ACS ДОЛЖЕН использовать digest authentication.

ACS может выдать аутентификацию один раз как часть первой HTTP-транзакции и предположить, что аутентификация сохраняется в течение TCP-соединения.

Если для аутентификации CPE используется любая форма HTTP-аутентификации, то CPE ДОЛЖЕН использовать username/userid, который глобально уникален между всеми производителями CPE. В частности это должна быть строка из нескольких компонентов, состоящая из идентификатора производителя (manufacturer identifier) и серийного номера (serial number), уникального для устройств этого производителя. РЕКОМЕНДОВАННЫЙ формат для этой строки:

   OUI-SERIAL

Здесь OUI это 6 hex-цифр значения, где все символы в верхнем регистре, включающего начальные нули. Значение OUI ДОЛЖНО быть допустимым OUI, как это определено в [9]. SERIAL это строка, которая уникально идентифицирует CPE конкретного производителя. Если у производителя есть несколько изделий CPE с пересекающимися диапазонами серийных номеров, то строка SERIAL ДОЛЖНА включать дополнительные символы отличий, гарантирующие уникальность строки серийного номера. Пример:

   "00D09E-0123456789"

Пароль, используемый в любой форме аутентификации HTTP, ДОЛЖЕН быть уникальным для каждого CPE. Т. е. несколько CPE НЕ ДОЛЖНЫ использовать одинаковый пароль. Этот пароль является shared-секретом, и он ДОЛЖЕН быть известен обоим сторонам, CPE и ACS. Описание метода, с которым shared-секрет становится известным обоим сторонам обмена, используемый на начальной инсталляции CPE, выходит за область обсуждения этой спецификации (см. секцию 2.2.1). Обе стороны, CPE и ACS, ДОЛЖНЫ предпринять соответствующие шаги, чтобы предотвратить неавторизованный доступ к паролю (в случае CPE) или к списку паролей (в случае ACS).

[3.5. Использование SOAP]

Протокол CWMP определяет SOAP 1.1 [8] в качестве синтаксиса кодирования транспорта для вызовов метода RPC и ответов, определенных в Приложении A.

Описание отображения методов RPC на кодирование SOAP:

• Кодирование должно использовать стандартный конверт SOAP 1.1 и пространство имен сериализации (serialization namespaces):

   - Идентификатор пространства имен конверта "http://schemas.xmlsoap.org/soap/envelope/".
   - Идентификатор пространства имен сериализации "http://schemas.xmlsoap.org/soap/encoding/".

• Все элементы и атрибуты, определенные как часть этой версии протокола CWMP, ассоциированы со следующим идентификатором пространства имен:

   - "urn:dslforum-org:cwmp-1-0"

• Типы данных, используемые в Приложении A, непосредственно соответствуют типам данных, определенным в пространстве имен сериализации SOAP 1.1 (как правило типы, используемые в Приложении A, являются ограниченными подмножествами типов SOAP).

• Для аргумента массива заданное имя аргумента соответствует имени общего элемента массива. Имена отдельных элементов элементов не задаются, поэтому их следует именовать по типу. Например, аргумент с именем ParameterList, который является массивом структур ParameterValueStruct, будет кодироваться следующим образом:

< ParameterList soap:arrayType="cwmp:ParameterValueStruct[2]">
   < ParameterValueStruct>
      < name>Parameter1< /name>
      < value xsi:type="someType">1234< /value>
   < /ParameterValueStruct>
   < ParameterValueStruct>
      < name>Parameter2< /name>
      < value xsi:type="someType">5678< /value>
   < /ParameterValueStruct>
< /ParameterList>

• Что касается спецификации SOAP для кодирования методов RPC (секция 7 из [8]), для каждого метода, определенного в Приложении A, каждый аргумент, указанный в вызове метода, представляет параметр [in], в то время как каждый аргумент, перечисленный в ответе метода, представляет параметр [out]. Для [in/out] параметры отсутствуют.

• Определенные методы RPC используют стандартное соглашение об именовании SOAP, в соответствии с которым ответное сообщение, соответствующее данному методу, именуется путем добавления префикса "Response" к имени метода.

• Ответ неудачной операции (fault response) ДОЛЖЕН использовать элемент SOAP Fault со следующими соглашениями:

   • Элемент SOAP faultcode ДОЛЖЕН показывать источник отказа (fault source), Client или Server, в зависимости от конкретного отказа. В этом использовании Client представляет отправителя запроса SOAP, а Server представляет ответчика SOAP.
   • Субэлемент строки отказа SOAP (faultstring) ДОЛЖЕН содержать строку "CWMP fault".
   • Элемент SOAP detail ДОЛЖЕН содержать структуру Fault, определенную в пространстве имен "urn:dslforumorg:cwmp-1-0". Эта структура содержит следующие элементы:

      - FaultCode, содержащий одиночный цифровой код отказа, как это определено в Приложении A.
      - FaultString, содержащий понятное для человека описание отказа.
      - SetParameterValuesFault, используемый в ответе ошибки (error response) для метода SetParameterValues, где содержится список из одной или большего количества структур, описывающих специфику отказа, связанные с каждым параметром в ошибке. Эта структура содержит следующие элементы:

         - ParameterName, где содержится имя полного пути параметра в ошибке.
         - FaultCode, содержащий одиночный цифровой код отказа (определен в Appendix A), который показывает отказ, связанный с определенным параметром в ошибке.
         - Элемент FaultString, содержащий понятное для человека описание отказа для определенного параметра в ошибке.

Сегмент XML-schema, который определяет структуру Fault:

< xs:element Name="Fault">
   < xs:complexType>
      < xs:sequence>
         < xs:element Name="FaultCode" Type="unsignedInt"/>
         < xs:element Name="FaultString" Type="string" minOccurs="0"/>
         < xs:element Name="SetParameterValuesFault" minOccurs="0" maxOccurs="unbounded">
            < xs:complexType>
               < xs:sequence>
                  < xs:element Name="ParameterName" Type="string"/>
                  < xs:element Name="FaultCode" Type="unsignedInt"/>
                  < xs:element Name="FaultString" Type="string" minOccurs="0"/>
               < /xs:sequence>
            < /xs:complexType>
         < /xs:element>
      < /xs:sequence>
   < /xs:complexType>
< /xs:element>

Пример конверта, содержащего fault response:

< soap:Envelope
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
   soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:cwmp="urn:dslforum-org:cwmp-1-0">
   < soap:Header>
      < cwmp:ID soap:mustUnderstand="1">1234< /cwmp:ID>
   < /soap:Header>
   < soap:Body>
      < soap:Fault>
         < faultcode>Client< /faultcode>
         < faultstring>CWMP fault< /faultstring>
         < detail>
            < cwmp:Fault>
               < FaultCode>9000< /FaultCode>
               < FaultString>Upload method not supported< /FaultString>
            < /cwmp:Fault>
         < /detail>
      < /soap:Fault>
   < /soap:Body>
< /soap:Envelope>

Пример конверта, содержащего fault response для вызова метода SetParameterValues:

< soap:Envelope
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
   soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:cwmp="urn:dslforum-org:cwmp-1-0">
   < soap:Header>
      < cwmp:ID soap:mustUnderstand="1">1234< /cwmp:ID>
   < /soap:Header>
   < soap:Body>
      < soap:Fault>
         < faultcode>Client< /faultcode>
         < faultstring>CWMP fault< /faultstring>
         < detail>
            < cwmp:Fault>
               < FaultCode>9003< /FaultCode>
               < FaultString>Invalid arguments< /FaultString>
               < SetParameterValuesFault>
                  < ParameterName>
                     InternetGatewayDevice.Time.LocalTimeZone
                  < /ParameterName>
                  < FaultCode>9012< /FaultCode>
                  < FaultString>Not a valid time zone value< /FaultString>
               < /SetParameterValuesFault>
               < SetParameterValuesFault>
                  < ParameterName>
                     InternetGatewayDevice.Time.LocalTimeZoneName
                  < /ParameterName>
                  < FaultCode>9012< /FaultCode>
                  < FaultString>String too long< /FaultString>
               < /SetParameterValuesFault>
            < /cwmp:Fault>
         < /detail>
      < /soap:Fault>
   < /soap:Body>
< /soap:Envelope>

• Для будущей расширяемости, когда обрабатывается принятый конверт, оба участника обмена, и ACS, и CPE, ДОЛЖНЫ игнорировать: (a) любые неизвестные элементы XML(4) и их субэлементы или содержимое, (b) любые неизвестные атрибуты XML и их значения, (c) любые встроенные комментарии XML и (d) любые инструкции обработки XML.

Примечание (4): за исключением приема неизвестного действия SOAP (unknown SOAP action), что должно приводить к fault response, показывающего, что метод не поддерживается (Method Not Supported, см. Приложение A [16]).

Протокол CWMP определяет последовательность элементов SOAP Header, показанные в таблице 3.

Таблица 3. SOAP Header Elements.

Пример сообщения, показывающий использование всех определенных заголовков:

< soap:Envelope
   xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
   soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:cwmp="urn:dslforum-org:cwmp-1-0">
      < soap:Header>
         < cwmp:ID soap:mustUnderstand="1">1234< /cwmp:ID>
         < cwmp:HoldRequests soap:mustUnderstand="1">0< /cwmp:HoldRequests>
         < cwmp:NoMoreRequests>1< /cwmp:NoMoreRequests>
      < /soap:Header>
      < soap:Body>
      < cwmp:Action>
         < argument>value< /argument>
      < /cwmp:Action>
   < /soap:Body>
< /soap:Envelope>

[3.6. Требования к поддержке RPC]

В таблице 4 представлено краткое описание всех методов и указаны условия, при которых реализация каждого метода RPC, определенного в Приложении A, является ТРЕБУЕМОЙ (REQUIRED) или НЕОБЯЗАТЕЛЬНОЙ (OPTIONAL).

Таблица 4. Требования к реализации методов RPC.

Примечания:

(5) Требуется только если поддерживаются загрузки файлов любого типа.
(6) Если механизм voucher поддерживается, то требуется реализация обоих методов SetVouchers и GetOptions.
(7) Требуется только если поддерживаются загрузки или выгрузки файлов любого типа.
(8) Требуется только если ACS поддерживает инициацию загрузки или выгрузки файлов.

[3.7. Процедуры сессии транзакций]

Все сессии транзакций ДОЛЖНЫ начинаться с сообщения Inform от CPE, в котором содержится начальный HTTP post. Это служит для инициации набора транзакций и информирования об ограничениях CPE в контексте кодирования сообщений.

Сессия прекращается, когда оба ACS и CPE больше не имеют ни запросов для отправки, ни ожидающих ответов со стороны ACS или CPE. В это время CPE может закрыть соединение. Одновременно может существовать не более одного сеанса транзакций между CPE и связанным с ним ACS.

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

3.7.1. Работа CPE

3.7.1.1. Инициация сессии. CPE будет инициировать сессию транзакции к ACS в результате наличия условий, перечисленных в секции 3.2.1. Как только соединение с ACS успешно установлено, CPE инициирует сессию путем отправки начального запроса Inform к ACS. Это показывает для ACS текущий статус CPE, и готов ли CPE принимать запросы от ACS.

В этом начальном HTTP post, в котором передается запрос Inform, разрешен только один SOAP-конверт. Аргумент MaxEnvelopes в Inform response показывает максимальное количество конвертов, которое может быть передано каждым последующим HTTP post.

CPE ДОЛЖЕН инициировать сессию только тогда, когда заблокировал Parameter-ы, доступные через этот интерфейс, чтобы гарантировать, что они не могут быть изменены через любой другой механизм. CPE ДОЛЖЕН сохранять эту блокировку, пока сессия не завершится.

3.7.1.2. Входящие запросы. При получении SOAP от ACS, CPE ДОЛЖЕН ответить на каждый запрос в том порядке, в каком поступили запросы, где порядок определяется в соответствии с описанием в секции 3.4.1. Это определение порядка не накладывает никаких ограничений на то, отправляются ли несколько ответов в одном HTTP post (если ACS может принимать более одного конверта), или они распределяются по нескольким HTTP post.

Для предотвращения взаимоблокировок CPE НЕ ДОЛЖЕН задерживать ответ на запрос ACS для ожидания ответа от ACS на более ранний запрос CPE.

3.7.1.3. Исходящие запросы. Когда у CPE есть сообщения запроса для отправки (после начального запроса Inform), он может послать их в любом порядке относительно ответов, отправляемых CPE в ACS. Т. е. CPE может вставить один или несколько запросов в любое место последовательности конвертов, которую он передает в ACS. Не существует определенного ограничения на количество запросов, которые CPE может отправить до получения ответов (количество невыполненных запросов). CPE МОЖЕТ, если это не обходимо, сам определить внутренний лимит.

Если CPE принял конверт от ACS (с запросом или ответом) в котором заголовок HoldRequests равен true (см. секцию 3.5), то CPE НЕ ДОЛЖЕН посылать любые запросы в последующих HTTP post-ах. CPE может перезапустить отправку конвертов только когда он позже примет конверт, где заголовок HoldRequests равен false (или, что эквивалентно, без заголовка HoldRequests). При определении возможности отправки запроса CPE ДОЛЖЕН проверить все конверты, полученные до конца самого последнего ответа HTTP. Из-за порядка конвертов, определенного в секции 3.4.1, только последний конверт в ответе HTTP определяет, разрешены ли запросы в следующем HTTP post. Если CPE принял пустой HTTP ответ от ACS, то это может быть интерпретировано как HoldRequests, равный false.

Если есть один или несколько невыполненных запросов от ACS,или если у CPE есть один или несколько невыполненных запросов и HoldRequests false, то CPE ДОЛЖЕН послать в ACS хотя бы один запрос или ответ в любом HTTP post. ДОЛЖЕН быть отправлен пустой HTTP post, если у ACS нет ожидающих передачи запросов или ответов. В таблице 5 приведен полный набор ограничений на то, что CPE ДОЛЖЕН отправлять во время сессии.

Таблица 5. CPE Message Transmission Constraints.

3.7.1.4. Завершение сессии. CPE ДОЛЖЕН прервать сессию транзакции, когда удовлетворяются все следующие условия:

1) У ACS больше не запросов для отправки в CPE. CPE заключает это, если одно из следующего true:

   a) Самый последний HTTP response от ACS не содержит конвертов.
   b) Самый последний конверт, полученный от ACS (в порядке, определенном секцией 3.4.1) включает заголовок NoMoreRequests, равный true (см. секцию 3.5). Использование этого заголовка устройством CPE является ОПЦИОНАЛЬНЫМ.

2) У CPE больше нет запросов для отправки в ACS.

3) CPE принял все ожидаемые сообщения ответа от ACS.

4) CPE отправил все ожидающие отправки сообщения ответа в ACS, как следствие его предыдущих запросов.

CPE ДОЛЖЕН также завершить сессию, если он не принял HTTP response от ACS за локально определенный период времени не менее 30 секунд.

Если выше перечисленные условия не выполняются, то CPE ДОЛЖЕН продолжать сессию.

Если одно или несколько сообщений, пересланных в течение сессии, привели к тому, что CPE нуждается в перезагрузке (reboot), чтобы завершить запрошенную операцию, то перед выполнением перезагрузки CPE ДОЛЖЕН дождаться полного завершения сессии в соответствии с выше перечисленными критериями.

Если сессия прервалась неожиданно, то CPE ДОЛЖЕН попытаться установить новую сессию, запуская процедуру установки сессии с самого начала. Для такого случая CPE МОЖЕТ разместить локально заданные лимиты количества попыток установить заново сессию.

3.7.2. Работа ACS

3.7.2.1. Инициация сессии. При получении начального запроса Inform от CPE, сервер ACS ДОЛЖЕН ответить сообщением Inform response. ACS может за этим послать серию запросов к CPE.

Аргумент MaxEnvelopes в запросе Inform показывает максимальное количество конвертов, которое может переносить каждый HTTP response, отправляемый от ACS к CPE. Если CPE может принять больше одного конверта, то начальный HTTP response, переносящий Inform response, может также нести в себе дополнительные запросы в пределах общего лимита MaxEnvelopes.

3.7.2.2. Входящие запросы. При приеме SOAP-запросов от CPE сервер ACS ДОЛЖЕН отвечать на каждый запрос в порядке их получения, где порядок определен в описании секции 3.4.1. Это определение порядка не накладывает никаких ограничений на то, отправляются ли несколько ответов в одном HTTP response (если CPE может принимать более одного конверта), или они распределяются по нескольким HTTP response.

Для предотвращения взаимоблокировок ACS НЕ ДОЛЖЕН задерживать ответ на запрос CPE для ожидания ответа от CPE на более ранний запрос ACS.

Если ACS хочет предотвратить отправку запросов от CPE в какой-то части сессии, то ACS может сделать это путем установки заголовка HoldRequests в true в каждом конверте, передаваемом в CPE, пока ACS снова не захочет получать запросы от CPE. ACS ДОЛЖЕН позволять запросы CPE перед завершением сессии (это может быть осуществлено явно через заголовок HoldRequests, или неявно путем отправки пустого HTTP response).

3.7.2.3. Исходящие запросы. Когда у ACS есть сообщения запроса для отправки, он может послать их в любом порядке по отношению к ответам, отправляемым от ACS к CPE. Т. е. ACS может вставлять один или большее количество запросов в любом месте последовательности конвертов, которые он передает (после Inform response). Не существует определенного ограничения на количество запросов, которые ACS может отправить до получения ответов (количество невыполненных запросов). ACS МОЖЕТ включать локально указанный предел, если это необходимо.

Если ACS имеет один или более запросов, оставшихся для отправки, и/или один или более ответов, ожидающих обработки из предыдущих запросов от CPE, то ACS ДОЛЖЕН отправить по меньшей мере один запрос или ответ в любом HTTP response, отправленном обратно в CPE. Пустой HTTP response допускается только в том случае, если в ACS больше нет невыполненных запросов или ответов.

3.7.2.4. Завершение сессии. Поскольку именно CPE управляет HTTP-соединением с ACS, то только CPE отвечает за инициацию и прерывание сессии.

ACS может считать сессию завершенной, когда удовлетворяются все следующие условия:

1) У CPE больше нет запросов для отправки в ACS. ACS заключает это, если одно из следующего true:

   a) Самый последний HTTP post от CPE не содержит конвертов.
   b) Самый последний конверт, полученный от CPE (в порядке, описанном секцией 3.4.1), включает заголовок NoMoreRequests, равный true (см. секцию 3.5). Использование этого заголовка сервером ACS является ОПЦИОНАЛЬНЫМ.

2) У ACS больше нет запросов для отправки в CPE.

3) CPE отправил все ожидающие сообщения ответов в ACS, которые были вызваны предыдущими запросами от ACS.

4) ACS получил все ожидаемые сообщения ответов от CPE.

Если не все перечисленные критерии выполняются, однако ACS не получил HTTP post от CPE в течение локально определенного таймаута не менее 30 секунд, то он может считать, что сессия завершена. В этом случае ACS МОЖЕТ попытаться заново установить сессию путем выполнения Connection Request (см. секцию 3.2.2).

3.7.3. Примеры транзакций TR-069. В примере, показанном на рис. 3, ACS сначала читает значения набора параметров, и на основании результата этой операции устанавливает значения некоторых параметров. В показанном примере MaxEnvelopes на обоих сторонах обмена равен 1, так что здесь нет ни конвейеризации запросов от ACS, ни нескольких запросов в каждом HTTP post от CPE.

Рис. 3. Пример транзакции, когда MaxEnvelopes == 1 как у CPE, так и у ACS.

Пример на рис. 4 показывает сценарий, где MaxEnvelopes на обоих сторонах обмена установлен в 3, позволяя тем самым создавать конвейер сообщений в обоих направлениях. В этом примере показаны несколько дополнительных запросов от ACS.

Рис. 4. Пример транзакции, когда MaxEnvelopes == 3 как у CPE, так и у ACS.

[Ссылки]

1. TR-069: CPE WAN Management Protocol https://www.broadband-forum.org/pdfs/tr-069-1-1-0.pdf.
2. TR-046: Auto-Configuration Architecture & Framework https://www.broadband-forum.org/pdfs/tr-046-1-0-0.pdf.
3. TR-062: Auto-Config for the Connection Between the DSL Broadband Network Termination (B-NT) and the Network using ATM (TR-037 update) https://www.broadband-forum.org/pdfs/tr-062-1-0-0.pdf.
4. TR-044: Auto-Configuration for Basic Internet (IP-based) Services https://www.broadband-forum.org/pdfs/tr-044-1-0-0.pdf.
5. RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1 http://www.ietf.org/rfc/rfc2616.txt.
6. RFC 2617, HTTP Authentication: Basic and Digest Access Authentication http://www.ietf.org/rfc/rfc2617.txt.
7. RFC 2965, HTTP State Management Mechanism http://www.ietf.org/rfc/rfc2965.txt.
8. Simple Object Access Protocol (SOAP) 1.1 http://www.w3.org/TR/2000/NOTE-SOAP-20000508.
9. Organizationally Unique Identifiers (OUIs) http://standards.ieee.org/faqs/OUI.html.
10. The SSL Protocol, Version 3.0 http://www.netscape.com/eng/ssl3/draft302.txt.
11. RFC 2246, The TLS Protocol, Version 1.0 http://www.ietf.org/rfc/rfc2246.txt.
12. RFC 2132, DHCP Options and BOOTP Vendor Extensions http://www.ietf.org/rfc/rfc2132.txt.
13. XML-Signature Syntax and Processing, http://www.w3.org/2000/09/xmldsig.
14. PKCS #7, Cryptographic Message Syntax Standard http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html, или http://www.ietf.org/rfc/rfc2315.txt.
15. TR-069 cwmp client implementation: open sources comparison site:stackoverflow.com.
16. TR-069, Приложение A: методы RPC.
17. 241107TR-069-CWMP-docs.zip - PDF-документы, относящиеся к стандарту CWMP/TR-069.