"ГОСТ Р 59802-2021. Национальный стандарт Российской Федерации. Телевидение вещательное цифровое. Расширенные технические требования к передаче транспортных потоков служб DVB по сетям с IP-протоколами. Часть 3. Процессы распределения адресов IP, реализации сетевых служб времени и обновления системного программного обеспечения домашнего оконечного оборудования. Основные параметры"
(утв. и введен в действие Приказом Росстандарта от 26.10.2021 N 1310-ст)

1 РАЗРАБОТАН Автономной некоммерческой организацией "Научно-технический центр информатики" (АНО "НТЦИ")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 "Связь"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 октября 2021 г. N 1310-ст

4 Настоящий документ разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций ETSI TS 102 034 V2.1.1 (2016-04) "Телевидение вещательное цифровое. Передача транспортных потоков MPEG-2 основных служб DVB по основным сетям IP" [ETSI TS 102 034 V2.1.1 (2016-04) "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks", NEQ]

5 ВВЕДЕН ВПЕРВЫЕ

Настоящий стандарт предусматривает расширение набора спецификаций ГОСТ Р 54994, относящихся к передаче служб DVB в транспортных потоках MPEG-2, по двунаправленным IP-сетям путем:

- распределения IP-адресов и сетевых служб времени;

- динамического управления службами, обеспечивающего эффективное использование пропускной способности сети;

- использования технологии IPv6 при назначении IP-адресов;

- использования системных заглушек загрузки файла для активирования обновления системного программного обеспечения HNED после цикла "выключение - включение" электропитания или перезагрузки программного обеспечения (ПО).

Требования настоящего стандарта следует учитывать при разработке, изготовлении и эксплуатации устройств DVB, а также при разработке, проектировании и эксплуатации ПО сетей DVB.

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

ГОСТ 7.67 Система стандартов по информации, библиотечному и издательскому делу. Коды названий стран

ГОСТ Р 53528 Телевидение вещательное цифровое. Требования к реализации протокола высокоскоростной передачи информации DSM-CC. Основные параметры

ГОСТ Р 54994-2012 Телевидение вещательное цифровое. Передача служб DVB по сетям с IP протоколами. Общие технические требования

ГОСТ Р 55697 Телевидение вещательное цифровое. Сервисная информация. Общие технические требования

ГОСТ Р 56170 Телевидение вещательное цифровое. Домашняя мультимедийная платформа. Класс 1.2. Основные параметры

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

3.1 В настоящем стандарте применены термины по ГОСТ Р 53528, ГОСТ Р 54994, ГОСТ Р 55697, ГОСТ Р 56170, а также следующие термины с соответствующими определениями:

3.1.1 интернет-протокол; IP (Internet protocol, IP): Межсетевой протокол пакетной передачи, который работает:

- с 32-битовыми адресами (версия IPv4) и со 128-битовыми адресами (версия IPv6), обеспечивая адресацию и маршрутизацию пакетов в сети;

- без установления соединения, не обеспечивает сохранение порядка следования пакетов и не гарантирует доставку пакетов.

3.1.2 клиент DNS (DNS client): Служба [программа (или модуль в программе)], предназначенная для получения IP-адреса удаленного компьютера при наличии его доменного адреса.

3.1.3 оконечное устройство домашней сети; HNED (Home Network End Device, HNED): Устройство, которое подключено к IP-сети через интерфейс IPI-1, является отправителем потока или приемником потока и обеспечивает функции навигации и визуализацию контента DVB-IPT.

3.1.4 потоковый протокол реального времени; RTSP (Real Time Streaming Protocol, RTSP): Прикладной протокол, предназначенный для использования в системах, работающих с мультимедийными данными.

3.1.5 предложение провайдера служб (SP offering): Набор потоков или служб, предлагаемых провайдером служб для конечного пользователя.

3.1.6 провайдер службы; SP (Service Provider, SP): Объект, предоставляющий службу пользователю.

3.1.7 провайдер службы Интернет; ISP (Internet Service Provider, ISP): Сторона, предлагающая пользователю службу доступа в Интернет.

3.1.8 провайдер службы контента; CSP (Content Service Provider, CSP): Объект, который приобретает, лицензирует контент у провайдеров контента и упаковывает контент в службу.

3.1.9 служба DVB-IPTV (Digital Video Broadcasting-Internet Protocol Television): Одна или несколько программ, передаваемых по IP под управлением провайдера службы.

Примечание - Программы для прямого потребления могут быть доступны при передаче по расписанию (Live Media Broadcast), по требованию (Content on Demand Services) или для локального хранения при работе службы загрузки контента (CDS).

3.1.10 Хост (host): Любое устройство, предоставляющее сервисы формата "клиент-сервер" в режиме сервера по каким-либо интерфейсам и уникально определенное на этих интерфейсах.

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

CA - гражданский адрес (Civic Address);

CDS - служба загрузки контента (Content Download Service);

CPE - оборудование, расположенное в помещении абонента/клиента (Customer Premises Equipment);

CRC - циклический избыточный код, использующий алгоритм нахождения контрольной суммы, предназначенный для проверки целостности данных (Cyclic Redundancy Check);

DHCP - протокол динамической конфигурации хоста (Dynamic Host Configuration Protocol);

DNS - система наименований доменов в сети Интернет (Domain Name System);

DSLAM - цифровой мультиплексор доступа к абонентской линии (Digital Subscriber Line Access Multiplexe);

DSM - динамическое управление службой (Dynamic Service Management);

DUID - уникальный идентификатор DHCP (DHCP Unique Identifier);

DVB-IPTV - цифровое телевизионное вещание по каналам с IP-протоколами;

DVBSTP - транспортный протокол DVB SD&S (DVB SD&S Transport Protocol);

EUI-64 - 64-битовый формат уникального идентификатора;

FUS - служба обновления встроенного программного обеспечения (Firmware Update Service);

FUSS - заглушка системы загрузки файлов (File Upload System Stub);

GZIP - утилита компрессии и декомпрессии файлов, использующая алгоритм Deflate (GnuZIP);

HN - домашняя сеть (Home Network);

IANA - администрация адресного пространства интернет (Internet Assigned Numbers Authority);

IPv4 - интернет-протокол версия 4 (Internet Protocol version 4);

IPv6 - интернет-протокол версия 6 (Internet Protocol version 6);

IPI - инфраструктура IP-протокола (Internet Protocol Infrastructure);

IPTV - IP телевидения (Internet Protocol TeleVision);

LMB - вещание медиа (Live Media Broadcast);

MAC - управление доступом к среде (Media Access Control);

MIME - многоцелевые расширения интернет-почты (Multipurpose Internet Mail Extensions);

NetBIOS - протокол для работы в локальных сетях (Network Basic Input/Output System);

NTP - сетевой протокол времени (Network Time Protocol);

OUI - уникальный идентификатор организации (Organizationally Unique Identifier);

PnP - "включай и работай" - технология быстрого определения необходимого конфигурирования и конфигурирования устройств в компьютере (plug-and-play);

PT - тип полезной нагрузки (Payload Type);

RMS - служба удаленного управления и встроенные программы (Remote Management and Firmware);

RTP - транспортный протокол реального времени (Real-time Transport Protocol);

SAP - протокол объявления сеанса (Session Announcement Protocol);

SDP - протокол описания сеанса (Session Description Protocol);

SD&S - обнаружение и выбор службы (Service Discovery and Selection);

SLAAC - механизм автоконфигурации узла (StateLess Address AutoConfiguration);

SNTP - простой протокол сетевого управления (Simple Network Time Protocol);

SSL - уровень безопасного сокета (Secure Socket Layer);

SSM - источник конкретной рассылки в режиме multicast (Source Specific Multicast);

TCP - протокол управления передачей (Transmission Control Protocol);

TLS - безопасность уровня транзакций (Transaction Layer Security);

ZIP - система почтовых индексов, используемая почтовой службой США (Zone Improvement Plan).

multicast - режим передачи (доставки, загрузки, источники передачи), служб, сеансов, потоков, каналов, протоколов, файлов подмножеству получателей (адресов),

unicast - режим передачи (доставки, загрузки, источники передачи) служб, сеансов, потоков, каналов, протоколов, файлов только одному получателю (адресу).

В общем случае каждому интерфейсу HNED требуется отдельный IP-адрес, который назначается DHCP-сервером.

Распределение IP-адреса, маски подсети, адреса DNS-сервера, шлюза по умолчанию, шлюза и сервера WINS/NetBIOS должно быть выполнено при динамическом распределении адресов через DHCP.

Протокол динамической конфигурации хоста DHCP представлен на рисунке 1.

Формат протокола иллюстрирует размеры параметров. Протокол позволяет сообщениям нести дополнительную информацию, кроме IP-адреса.

В таблице 1 приведены описания полей протокола DHCP.

DHCP-клиент должен поддерживать все сообщения DHCP-сервера.

Пространство номеров опций DHCP (от 1 до 254) разделено на две части. Опции, предназначенные для личного использования, обозначены числами 128 - 254; общедоступные опции - числами 0 - 127 и 255. Указатели имен классов опций DHCP обязательного применения представлены в таблице 2.

Опция 57 DHCP "Maximum DHCP Message Siz" определяет максимальный размер сообщения DHCP. Ее применение обязательно при размере сообщения DHCP, превышающем 378 байт.

Опция 47 DHCP "NetBIOS over TCP/IP Name Server" применяется только при необходимости подключения HNED к серверам, использующим NetBIOS.

Опция 77 DHCP "User class" определяет многопользовательские классы DHCP и реализуется в среде клиента DHCP. Предоставление опций для многопользовательских классов выполняется удаленной системой управления добавлением дополнительных имен классов.

Опция 82 DHCP "Relay agent information" не обязательна при применении HNED.

В случае недоступности для HNED удаленного DHCP-сервера обмен в домашней сети между устройствами домашней сети следует сохранять при использовании адресов сети, предназначенных для соединений в границах сегмента домашней сети. Процесс формирования этих адресов выполняется в рамках автоконфигурации созданием локального адреса связи (link-local address), который позволяет обращаться к хосту. При этом общий префикс адреса не используется.

Настоящий стандарт не допускает размещения в домашней сети более одного DHCP-сервера независимо от того, являются ли они для DNG внутренними или внешними.

Выделение сервера DNS по умолчанию выполняется через DHCP.

Настоящий стандарт не требует реализации в HNED режима универсального PnP. Допускается опциональное применение режима PnP.

При реализации в HNED DHCP-сервера для обеспечения возможности функционирования в сети единственного активного сервера DHCP должна быть предусмотрена возможность включения и отключения этого сервера.

Адрес сервера повторной передачи RTP может быть получен при использовании опции Vendor-Identifying Vendor Specific Information.

При использовании опции повторной передачи RTP и при получении адреса сервера через DHCP устройство HNED должно применять опцию 125 информации поставщика Vendor-Identifying Vendor Specific Information, содержащую номер организации DVB 2696 с кодом субопции 10, содержащую список IP-адресов или URL серверов повторной передачи RTP. Серверы, к одному из которых должен подключиться HNED, размещаются в порядке приоритета от первого до последнего. Методы подключения к серверу и обеспечения его работы определяет провайдер.

Параметр расположения CellID может быть получен при использовании опции 99 DHCP GEOCONF_CIVIC. Эта опция позволяет DHCP-серверу предоставлять информацию о стране и почтовом адресе HNED при передаче от HNED на сервер DHCP адреса клиента в поле chaddr. Информация о стране должна соответствовать ГОСТ 7.67.

На рисунке 2 показан формат опции GEOCONF_CIVIC. Поле what должно иметь значение 2, а код страны должен соответствовать стране, в которой расположено HNED.

Почтовый адрес состоит из нескольких частей, содержание которых зависит от страны отправления. Опция делит части почтового адреса на поля с индексами типов гражданских адресов CAtype. В таблице 3 приведены примеры CAtype.

HNED может принимать любой из CAtype, включая поля личной информации. Рекомендуется использовать почтовый код, содержащий информацию о расположении, в достаточном для применения полном объеме информации. Все поля закодированы в windows-1251. Список CAtype должен быть пронумерован.

Если для указания расположения провайдер службы сети применяет другой элемент гражданского адреса, то он должен использовать для этой цели значения CAtype вне диапазона значений 0 - 128.

Содержание элементов гражданского адреса, ранее полученных HNED от DHCP-сервера, используется для получения CellID от сервера SD&S двумя способами:

- передачей этих элементов контента на сервер SD&S;

- сопоставлением элементов контента с таблицей, предоставленной SD&S.

Технология получения CellID от сервера SD&S настоящим стандартом не нормируется.

На рисунке 3 показаны элементы гражданских адресов.

HNED может получить IP-адрес методом SLAAC или от сервера версии DHCPv6.

Распределение IP-адреса, маски подсети, адреса DNS-сервера, адреса шлюза выполняется только при динамической адресации.

При назначении IP-адреса методом SLAAC для HNED выделяется 64-битовый префикс адреса IPv6 (префикс субсети DNG), который дополняется 64-битовым IPv6-адресом HNED (идентификатором интерфейса), являющимся уникальным идентификатором [Extended Unique Identifier (EUI-64)]. Использование EUI-64 обеспечивает уникальность автоконфигурации IPv6-адреса на глобальном уровне.

Назначение 64-битового префикса DNG выполняется в 64-битовом формате EUI-64 по ссылке на 48-разрядный MAC-адрес с переформатированием этого значения в соответствии со спецификацией EUI-64.

Назначение IP-адреса группы получателей с использованием DHCPv6 позволяет DNG действовать в качестве маршрутизатора DHCP и передавать в HNED сетевые адреса IPv6. Такой метод обеспечивает автоматическое распределение сетевых адресов группы получателей и дополнительную гибкость конфигурации.

В состав DHCPv6 входят несколько сообщений. Сообщения DHCP имеют заголовок фиксированного формата и область, содержащую опции переменного формата. Опции используют для обмена информацией между HNED и сервером DHCP. Формат сообщения DHCPv6 показан на рисунке 4.

В состав сообщения DHCPv6 входят следующие поля:

- msg-type - идентификатор типа сообщения DHCP;

- transaction-id - идентификатор транзакции обмена сообщениями;

- options - опции, переносимые в этом сообщении.

Однозначность обмена сообщениями между HNED и сервером DHCP обеспечивается идентификацией каждого устройства уникальным идентификатором DHCP (DHCP Unique Identifier, DUID).

Архитектура протокола IPv6 не предусматривает отображения всех опций DHCPv4 в соответствующих опциях DHCPv6. Таблица 4 обязательных опций DHCPv4 и их функциональных аналогов опций DHCPv6 содержит информацию о функциональных аналогах опций IPv6. Строки этой таблицы перечислены в порядке возрастания номеров опций DHCPv4 согласно приложению А.

Сообщения DHCPv6 передаются через UDP-порты 546 и 547. Клиенты прослушивают сообщения DHCP на UDP-порте 546, серверы - сообщения DHCP на UDP-порте 547.

Для сообщений DHCPv6 ограничения на их размер не устанавливаются.

DHCPv6 не поддерживает опции NetBIOS.

Опция класса пользователя DHCP должна быть реализована в HNED для классов, перечисленных в таблице 2. Пользователь не может изменять имена этих классов, однако система управления провайдера служб может добавлять дополнительные имена классов.

Информация агента ретрансляции DHCP в среде IPv6 не используется.

В случае недоступности в среде IPv6 DHCP-сервера устройства в домашней сети должны сохранять возможность обмена данными друг с другом, используя адреса сети, предназначенные только для соединений в пределах сегмента домашней сети. Процесс формирования этих адресов выполняется в рамках автоконфигурации путем создания локального адреса связи (link-local address), который позволяет обращаться к хосту без задействования общего префикса адреса.

Для IPv6 в качестве локального адреса связи выделена подсеть FE80::/10. Адрес формируется на основе уникального идентификатора интерфейса EUI-64.

Взаимосвязь HNED с DHCP-серверами в среде IPv6 HNED может быть установлена при использовании multicast-адреса FF02::1:2. С этой целью HNED отправляет сообщение Solicit и ожидает приема сообщения Advertise. После получения сообщений Advertise HNED запускает процесс выбора DHCP-сервера.

HNED может отправлять сообщения непосредственно на выделенный сервер, используя unicast-рассылки. С этой целью сервер отправляет клиенту опцию 12 Unicast Server, сообщая о том, что клиенту разрешено отправлять одноадресные сообщения на сервер. Формат опции Unicast Server содержит следующие поля:

- option-code, содержащее код и номер опции OPTION_UNICAST (12);

- option-len, содержащее длину опции 16 байт;

- server-address, содержащее IP-адрес, на который клиент должен отправлять сообщения с помощью unicast-рассылки.

Выделение DNS-сервера и шлюза по умолчанию должно быть осуществлено через опцию 23 DHCPv6 (см. таблицу 4). По умолчанию в списке адресов IPv6 DNS первая запись должна указывать шлюз для используемого HNED.

Настоящий стандарт не требует реализации в HNED технологии "включай и работай" (PnP). Допускается опциональное применение этой технологии.

При реализации в составе HNED сервера DHCP должна быть обеспечена возможность включения и отключения этого сервера, обеспечивая тем самым возможность работы в сети только одного активного сервера DHCP.

Адрес сервера повторной передачи RTP и последующие расширения DVB DHCP, а также другие варианты DVB могут быть доставлены с использованием двух опций DHCPv6:

- опции 16 Vendor Class - класса поставщика;

- опции 17 Vendor Specific Information - информация о конкретном поставщике.

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

- код опции OPTION_VENDOR_CLASS - 16;

- данные класса поставщика;

- номер предприятия, зарегистрированный в IANA;

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

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

Опция 17 используется клиентами и серверами для обмена информацией о конкретном поставщике. Формат опции содержит поля, описывающие:

- код опции: OPTION_VENDOR_OPTS - 17;

- длину поля данных опции, выраженную в байтах;

- номер предприятия, зарегистрированный в IANA;

- непрозрачный объект байтов option-len, интерпретируемый кодом конкретного поставщика на клиентах и серверах.

В обеих опциях используется номер предприятия, определяющий поставщика данных, передаваемых в этих опциях. В соответствии с IANA номер предприятия DVB составляет 2696.

В первую очередь HNED должно отправить опцию 16 с номером предприятия DVB 2696 и классом поставщика 2.

HNED, используя опцию повторной передачи RTP и получая адрес сервера через DHCPv6, должно получить опцию 17 информации, специфичной для поставщика, которая содержит номер предприятия DVB 2696 и область данных, содержащую список IP-адресов или URL серверов повторной передачи RTP. Способы подключения к серверу и обеспечения его работы определяет поставщик.

Параметр расположения для CellID образуется при использовании опции 36 DHCPv6, GEOCONF_CIVIC. Эта опция позволяет DHCP-серверу указывать страну и почтовый адрес HNED на основе адреса клиента HNED. При применении HNED этой опции DHCP-сервер должен предоставить соответствующие элементы гражданского адреса для работы CellID.

На рисунке 5 показан формат опции GEOCONF_CIVIC для DHCPv6. Поле what должно иметь значение 2, а поле country code должно указывать страну местонахождения HNED в соответствии с ГОСТ 7.67.

Почтовый адрес состоит из нескольких частей, содержание которых зависит от страны. Опция делит части почтового адреса на поля с индексами CAtype (см. таблицу 3). HNED может принимать любой индекс из CAtypes, включая поля личной информации. Рекомендуется использовать коды (индексы) post/zip, обеспечивающие достаточную информацию о расположении. Все поля должны быть закодированы в windows-1251. Список CAtype должен быть пронумерован.

Если сеть или поставщик служб используют другие элементы гражданского адреса для указания расположения, например имя DSLAM, следует применять значения CAtype с номерами вне диапазона значений от 0 до 128.

Для HNED должны быть предоставлены два типа служб сетевого времени:

- службы сетевого времени для приложений часов реального времени с погрешностью отсчета не более 100 мс;

- службы сетевого времени для транспортного потока с погрешностью отсчета не более 50 мс.

Обе службы могут функционировать одновременно при использовании общего сервера времени.

Часы реального времени в HNED должны быть реализованы с использованием протокола SNTP (Simple Network Time Protocol).

NTP (Network Time Protocol) версия 4 должен быть реализован для служб времени с точностью от 1 до 50 мс. Например, часы с такой точностью могут потребоваться при декодировании контента, инкапсулированного в транспортном потоке.

HNED должно выполнять поиск адреса сервера времени использованием:

- опции DHCP Network Time Protocol Servers (DHCPv4 опция 42 или DHCPv6 опция 56);

- метода, определенного изготовителем (опционально).

Примечание - Использование открытых серверов времени NTP приведет к значительным накладным расходам на этих серверах. Рекомендуется использовать выделенные серверы времени NTP.

Этот раздел формирует требования к расширенной системе обновления удаленного управления и прошивки для служб DVB-IPTV, позволяющей обновлять системное ПО HNED после цикла "выключение - включение" электропитания или перезагрузки ПО.

FUSS должны поддерживаться каждым HNED. Однако загрузка и замена системного ПО, на которое указывает заглушка, должны быть осуществлены при условии выполнения провайдером необходимых мер безопасности.

Процедура обновления встроенного ПО HNED включает несколько этапов:

- получение файла-заглушки при unicast- или multicast-передаче. Имя файла в случае unicast-передачи должно быть dvb-ipi-fus-stub.dvb;

- исследование файла-заглушки с целью поиска возможных объектов ПО для обновления;

- загрузка обновления (опционально);

- выполнение провайдером мер безопасности и замена существующего ПО (опционально).

Правила получения расположения файла-заглушки описаны в 5.2.1.

Правила получения файла-заглушки при multicast-адресации и unicast-адресации описаны в 5.2.2 и 5.2.3 соответственно.

Запускаемое устройства должно найти URL или IP-адрес файла-заглушки в следующем порядке и следующими методами:

а) при проверке содержания поля siaddr сервера DHCP если поле siaddr содержит допустимый в режиме unicast IP-адрес, то устройство должно получить файл-заглушку по HTTP (HTTPS) с URL: http(s): //siaddr/dvb-ipi-fus-stub.dvb;

б) если поле siaddr содержит допустимый в режиме multicast адрес, то устройство должно получить файл, используя DVBSTP в соответствии с методом по перечислению а);

в) если поле siaddr содержит 0 или IP-адрес недопустим, то устройство должно проверить опцию 67 DHCPv4 Bootfile Name или опцию 67 DHCPv6 Bootfile URL.

В свою очередь, опция Bootfile URL должна содержать:

1) полный URI для файла, который использует HTTP (HTTPS) для unicast-метода по методике, приведенной в перечислении а),

2) IP-адрес в режиме multicast с последующим использованием для загрузки DVBSTP методом по перечислению в). Имена файлов или URI, не имеющих расширения dvb, должны игнорироваться. Порядок проверки нескольких URI с расширением dvb в настоящем стандарте не установлен,

3) если опция Bootfile не содержит имени загрузочного файла или IP-адреса, то устройство должно прослушивать IGMPv3/SSM адрес 232.255.255.254 для IPv4 и SSM-адрес FF3F::FFFF:FFFE - для IPv6 (HNED не должно прослушивать этот адрес более 10 с);

г) IP-адрес файла-заглушки может быть получен, если изготовитель выполнит кодирование URL или IP-адреса в поле, работающем с HTTP или DVBSTP.

После получения в режиме multicast адреса HNED должно его прослушивать на порте 3937 (dvbservdsc), назначенном IANA. Для получения полезной нагрузки, содержащей файл-заглушку, прослушиваются идентификатор полезной нагрузки 0x08 и идентификатор сегмента 0x00. Для определения файла-заглушки, предназначенного для конкретного HNED, используется ServiceProviderID.

Семантика полей DVBSTP, описанная в приложениях Б, В, при получении через multicast файла-заглушки, должна корректироваться по следующим правилам:

Compression (Compr): при значении поля 000 файл-заглушка не должен компрессироваться;

ProviderID Flag (P): флаг сигнализирует, что значение 1 определяет наличие в заголовке поля ServiceProviderID и что SP предоставляет multicast-рассылку нескольких файлов-заглушек в HNED. Установка флага ProviderID и использование идентификатора SP необязательны;

ServiceProvider ID: 32-битовое число, которое используется для идентификации провайдера файла-заглушки. 32-битовое число формируется из 24-битового ManufacturerOU. В 8 финальных битах должны быть установлены 0. HNED проверяет ServiceProviderID, и, если флаг ProviderID установлен в 1, оно сравнивает нижние 24 бит содержимого идентификатора ServiceProviderID с ManufacturerOUI. Если ServiceProviderID совпадает со своим ManufacturerOUI, то следует использовать полезную нагрузку DVBSTP. В случае несовпадения сообщение DVBSTP должно быть проигнорировано, и HNED должно вернуться к анализу многоадресного трафика;

CRC: 32-битовый CRC следует применять (опционально), если в полезной нагрузке отсутствует заголовок Manifest. Должен использоваться стандартный CRC, который применяется к данным полезной нагрузки всех секций, составляющих сегмент. Это поле может не совпадать с 32-битовой границей.

При HTTP(S) адрес в режиме unicast доставки файла-заглушки указывается в поле siaddr сообщений DHCP:

- если поле siaddr переносит допустимый IP-адрес в режиме unicast-передачи, а HNED подтверждает поддержку операции SSL/TLS, HNED может получить файл-заглушку, используя URL:/template/go.php?url=https://siaddr/dvb-ipi-fus-stub.dvb;

- если поле siaddr переносит допустимый IP-адрес в режиме unicast-передачи, а операции SSL/TLS не поддерживаются или HTTPS не работает, то операция получения адреса в режиме unicast-доставки файла-заглушки должна повторяться с использованием URL: /template/go.php?url=https://siaddr/dvb-ipi-fus-stub.dvb.

Полный URI файла-заглушки HTTP(S) может быть перенесен в опции 67 DHCP Bootfile name, например: /template/go.php?url=https://10.1.5.51/stub_repository/ dvb-ipi-fus-stub.dvb.

Предотвращение перегрузки необходимо в тех случаях, когда множество HNED из-за отключения электропитания или сбоев других видов при запуске отправляют данные, перегружающие серверы FUS.

По времени задержка попытки HNED установления соединения с сервером HTTP(S) должна быть установлена на 2 с. Непосредственно перед каждой попыткой установления соединения вносится дополнительная задержка случайной величины в интервале значений от 2 до 4 с. После каждого отказа установления соединения величина задержки должна быть удвоена. После 15-го отказа установления соединения эти попытки должны быть прекращены.

Форматом файла-заглушки может быть простой текстовый формат, доступный анализу. Контент файла-заглушки является подмножеством метаданных. Он может быть отправлен в кодированной или в некодированной форме. Кодированная форма обозначается Coding, а в некодированной форме использованы полные имена. Все файлы имеют заголовок вида [_DVB-STUB-HEADER-v1.0].

Формат кодированных элементов файлов-заглушек представлен в таблице 5 с обозначением формы кодирования, которое после значения номера формы кодирования имеет добавленный символ "=". Элементы разделяются символом ";".

Допускается использование URI двумя способами:

- при unicast-рассылке - URI указывает на файл образа задачи (file image) при загрузке непосредственно из FUS;

- unicast- и multicast-рассылке URI указывает на сообщение указателя в службе multicast-рассылки или на сообщение с описанием, полученным из FUS, идентифицирующим загрузку.

При идентификации службы multicast-рассылки рекомендуется использовать URI-форму dvb-mcast URL-адреса путем применения полей multicast-адреса/протокола. URI dvb-mcast определен в приложении В.

Перечень общедоступных необязательных для применения опций DHCPv4 представлен в таблице А.1.

Семантика multicast DVBSTP должна соответствовать ГОСТ Р 54994-2012 (5.4.3.1) с учетом измененной семантики следующих полей:

- Ver (Protocol Version): поле 2 бита. Поле Ver должно принимать значение, указанное в таблице Б.1, соответствующее версии протокола IP.

- Compression (Compr) (компрессирование): поле 3 бита обозначает применяемую схему компрессирования полезной нагрузки. Все сегменты, относящиеся к данному идентификатору полезной нагрузки, должны иметь одинаковую схему компрессирования. Типы схем компрессирования приведены в таблице Б.2. Схема компрессирования GZIP доступна со значением идентификатора полезной нагрузки, равным 0x08 для использования с RMS/FUS, или для идентификатора полезной нагрузки со значением, равным 0x07, с записью информации регионирования.

- ServiceProviderID: поле содержит ID провайдера служб. Семантика этого поля зависит от используемого сетью IPv4 или IPv6;

- для IPv4: это 32-разрядное число, представляющее адрес IPv4, который используется для идентификации провайдера служб. Данное число должно быть адресом IPv4. Остальная часть поля должна игнорироваться;

- для IPv6: это 128-разрядное число, переносимое в виде четырех 32-битовых слов, представляющее адрес IPv6, который используется для идентификации провайдера служб. Должны быть указаны все цифры адреса IPv6, включая начальные нули.

SP несет ответственность за поддержку этого адреса соответствующими полномочиями и за поддержку уникальности значения в пределах области, в которой он используется. Поле ServiceProviderID применяется только HNED.

Поле ServiceProviderID является обязательным для использования, если провайдер знает, что другие провайдеры служб не могут применять этот адрес multicast-доставки.

Схема URI DVB-MCAST определена для идентификации ресурсов, предоставляемых через multicast-канал IP. Она предоставляет средства для поиска канала multicast-передачи ресурса, а также информации о транспортном протоколе уровня приложения, который будет использоваться для переноса данных по multicast-каналу, например протоколы SAP, DVBSTP.

В разделе В.2 определяется базовая схема. В разделах В.3 и В.4 определяются конкретные расширения и варианты использования схемы для поиска по ссылке описания сеансов загрузки при использовании протоколов DVBSTP и SAP.

Базовая схема URI DVB-MCAST, определенная в этом разделе, предоставляет клиенту информацию, необходимую для присоединения к multicast-каналу IP. В схему включен набор параметров, требуемых протоколом multicast-соединения. Предоставляя (опционально) тип транспортного протокола прикладного уровня, клиент сможет направить данные из multicast-канала в соответствующее приложение. Эта схема может быть расширена для конкретного использования транспортного протокола прикладного уровня.

Базовая схема URI DVB-MCAST определена следующим образом:

dvb-mcast:// [src-host @ ] mcast-addr : port [?payload= PayloadID]

Элемент mcast-addr указывает multicast-адрес, к которому должен присоединиться клиент.

Элемент port указывает порт назначения UDP при приеме потока unicast-передачи.

Элемент src-host является опциональным, относящимся к multicast-адресу IP источника данных multicast-передачи. Этот элемент используется для поддержки источника multicast-рассылки (SSM).

Базовая схема URI DVB-MCAST, определенная в разделе В.2, расширяется для обеспечения возможности поиска по ссылке конкретных элементов протокола DVBSTP - SP, PT и сегментов. Идентификатор SP DVBSTP, идентификатор полезной нагрузки и идентификатор сегмента являются частями компонента Query (запроса) URI. Они предоставляют информацию для поиска определенного сегмента в multicast-канале DVBSTP.

Примечание - Номер версии сеанса в схеме URI не указывается. В схеме URI используется последняя версия сегмента, распределенного по multicast-каналу.

Для формирования ссылки на конкретное описание сеанса в сегменте XML идентификатор сеанса загрузки CDS предоставляется внутри фрагмента URI. Синтаксис фрагмента поставляемого контента определен описанием сеанса CDS XML.

Схема URI DVB-MCAST для DVBSTP определена следующим образом:

dvb-mcast:// [ src-host @ ] mcast-addr : port ?payload=dvbstp [&service-provider= ServiceProviderID] [&dvbstp-payload= DVBSTPPayloadID] [&segment= SegmentID] [#? dvb-cds- session-id= Download-Session-ID]

Для получения доступа к указанному ресурсу устройство должно присоединиться к группе многоадресной передачи, предоставленной элементами mcast-addr, port и src-host в URI. Устройство сравнивает все параметры, предоставленные в компоненте запроса URI, с соответствующими полями протокола DVBSTP и извлекает все соответствующие сегменты. Параметры в компоненте запроса URI являются опциональными. Если параметр не указан, то соответствующее поле в протоколе DVBSTP не используется при сравнении параметров.

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

Базовая схема URI DVB-MCAST, определенная в разделе В.2, расширяется, обеспечивая возможность поиска по ссылке данных SDP, предоставляемых через протокол SAP. Тип полезной нагрузки устанавливается sap. Дополнительная информация в запросе URI не предоставляется.

Идентификатор сеанса загрузки CDS может быть использован в качестве ссылки на описание сеанса в информации SD. Идентификатор сеанса загрузки CDS может быть предоставлен в фрагменте URI.

Схема DVB-MCAST URI для SAP определена следующим образом:

dvb-mcast:// [ src-host @ ] mcast-addr : port ?payload=sap [#? sdp-session-id= Download-Session-ID]

Download-Session-ID = целое число без знака.

В случае предоставления в компоненте фрагмента URI идентификатора сеанса загрузки устройство должно выполнить поиск всей информации SDP, переданной по multicas-каналу, и описание сеанса с конкретным идентификатором сеанса загрузки.