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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Телевидение вещательное цифровое

РАСШИРЕННЫЕ ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ПЕРЕДАЧЕ ТРАНСПОРТНЫХ ПОТОКОВ СЛУЖБ DVB ПО СЕТЯМ С IP-ПРОТОКОЛАМИ

Часть 3

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

[ETSI TS 102 034 V2.1.1 (2016-04), NEQ]

Издание официальное

Москва Российский институт стандартизации 2021

Предисловие

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

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

• 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 октября 2021 г. № 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 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (ло состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

©Оформление. ФГБУ «РСТ». 2021

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

Содержание

• 1 Область применения

• 2 Нормативные ссылки

• 3 Термины, определения и сокращения

• 4 Распределение IP-адресов и сетевые службы времени

• 4.1 Адресация и маршрутизация интернет-протокола

• 4.2 Назначение IP-адресов при использовании методов IPv6

• 4.3 Службы сетевого времени

• 5 Системные заглушки загрузки файла для активирования обновления системного программного обеспечения HNED

• 5.1 Общие положения

• 5.2 Получение файла-заглушки

• 5.3 Формат файла-заглушки

Приложение А (справочное) Опции DHCPv4, необязательные для применения

Приложение Б (обязательное) Семантика многоадресного транспортного протокола DVB SD&S .... 19

Приложение 8 (обязательное) Схема DVB-MCAST URI

ГОСТ Р 59802—2021

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Телевидение вещательное цифровое

РАСШИРЕННЫЕ ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ПЕРЕДАЧЕ ТРАНСПОРТНЫХ ПОТОКОВ СЛУЖБ DVB ПО СЕТЯМ С 1Р-ПРОТОКОЛАМИ

Часть 3

Процессы распределения адресов IP, реализации сетевых служб времени и обновления системного программного обеспечения домашнего оконечного оборудования.

Основные параметры

Digital video broadcasting. Extended technical requirements to transport of MPEG-2 TS DVB services over IP vetwocks. Part 3. IP address allocation, network time services implementation and home endpoint system software upgrade processes. Basic parameters

Дата введения — 2022—06—01

• 1 Область применения

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

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

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

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

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

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

• 2 Нормативные ссылки

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

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

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

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

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

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

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

Издание официальное

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

• 3 Термины, определения и сокращения

  • 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): Одна или несколько программ, передаваемых no IP под управлением провайдера службы.

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

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

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

СА — гражданский адрес (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 Multiplexed

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);

РТ — тип полезной нагрузки (Payload Туре);

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 — режим передачи (доставки, загрузки, источники передачи) служб, сеансов, потоков, каналов. протоколов, файлов только одному получателю (адресу).

• 4 Распределение IP-адресов и сетевые службы времени

  • 4.1 Адресация и маршрутизация интернет-протокола

• 4 .1.1 Назначение IP-адресов при использовании методов IPv4

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

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

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

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

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

Таблица 1 — Описания полей протокола DHCP

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

4.1.2 Описание опций DHCP

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

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

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

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

Таблица 2 — Указатели имен классов

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

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

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

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

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

При реализации в 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, размещаются в порядке приоритета от первого до последнего. Методы подключения к серверу и обеспечения его работы определяет провайдер.

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

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

0 12 9

012S15H J»0 12 ! 458 7« S HI J4 5 6 7 « >01

•»—ь«—ь-4—4—4-4— 4—44—44-4-4- 4—4-4- 4—4-4- 4—4-4- 4—4-4—4—4-+

I asoco№_GX73C I v I xfcat | ceuatxy ... I 4-Ч-+-4—4-+-4-Ч .«-W-+-4-4 .^W^w-+-4-Ч -4- 4-+-+-4-+-+-4-Ч- ♦

I ... coda | olvlo асМгаав eleaeata

Рисунок 2 — Формат опции GEOCONF_CMC

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

Таблица 3 — Пример некоторых типов гражданских адресов CAtype

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

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

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

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

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

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

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

D 1 2 3

01234567B901234567B9D12345678901 ♦ III I I I I —4 —4 "Ч ™Ч **Ч —4 "Ч —4 "Ч "Ч "Ч —4—Ч ™Ч **Ч —4 **Ч —4

I CAtype I CAl«>gth I CAvalue ...

+-*«ч-4~*-Ч—4>ч—4~4~4"Ч-ч«»4—4-ч—4-ч—4-ч—4«ч—4«ч^^—4—4—4«ч-ч«ч«ч

Рисунок 3 — Элементы гражданских адресов

• 4.2 Назначение IP-адресов при использовании методов IPv6

• 4.2.1 Общие положения

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

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

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

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

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

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

0 12

О 1 8 3 I S S 7 8 S 0 1 2 М Я 1 8 » 0 1 2 3 4 5 «1 $ М 1

I saad-type transaction-id

I

. option»

. (variable)

I

Рисунок 4 — Формат сообщения DHCPv6

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

• - msq-type — идентификатор типа сообщения DHCP:

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

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

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

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

Таблица 4 —Сгмсок обязательных опций DHCPv4 и их функциональных аналогов опций ОНСРтб

Продолжение таблицы 4

Окончание таблицы 4

• 4.2.2 Реализация функций IPv6

Сообщения 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, содержащее код и номер опции OPTIONJJNICAST (12);

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

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

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

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

При реализации в составе 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. интерпретируемый кодом конкретного поставщика на клиентах и серверах.

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

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

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

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

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

0 12

0 1 2 3 4 5 в 78 9 0 1 2 Э 4 5 6 7 8 9 0 1 2 3 4 S « 7 В 9 О 1

-+-+-b -b-b-+ h—f—I—fr- +-fr—•—fr-+—

I amOKJBOCOHFCXWC | <фЪ1ОЛ-1«Л

-+-+-b —t—t~+ fr-+—►—fr-

I what country code

+-++-I— +-+-+ -+ -+ - +—t-

olvio абФге»» eleeent»

-+-+^ -♦-»-* -*-♦—»-+W-+- +-^-+-+- +-*-»

Рисунок 5 — Формат опции GEOCONF_CIVIC для DHCPv6

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

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

• 4.3 Службы сетевого времени

• 4.3.1 Типы служб сетевого времени

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

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

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

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

• 4.3.2 Часы реального времени или другие приложения с точностью 100 мс

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

• 4.3.3 Службы точного времени

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

• 4.3.4 Определение адреса сервера времени

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

• - опции DHCP Network Time Protocol Servers (DHCPv4 опция 42 или DHCPvS опция 56):

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

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

• 5 Системные заглушки загрузки файла для активирования обновления системного программного обеспечения HNED

• 5.1 Общие положения

Этот раздел формирует требования к расширенной системе обновления удаленного управления и прошивки для служб 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 соответственно.

• 5.2 Получение файла-заглушки

  • 5.2.1 Определение местоположения файла-заглушки

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

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

• 6) если поле 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-flnn IPv6 (HNED не должно прослушивать этот адрес более 10 с);

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

• 5.2.2 Использование DVBSTP при получении файла-заглушки через multicast

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

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

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

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

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

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

• 5.2.3 Использование HTTP(S) для получения файла-заглушки через unicast

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

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

• - если поле siaddr переносит допустимый IP-адрес в режиме unicast-передачи, а операции SSU TLS не поддерживаются или HTTPS не работает, то операция получения адреса в режиме unicast-доставки файла-заглушки должна повторяться с использованием URL: http: //siaddr/dvb-ipi-fus-stub.dvb.

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

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

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

• 5.3 Формат файла-заглушки

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

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

Таблица 5 — Формат элементов файлов-заглушек

Пример — запись информации в некодированной форме:

[_DVB-STUB-HEADER • v1.0]

[DeviceClassInfo]

ManufacturerOUI = 4567

Productclass = Fred

Hardwareversion = 1.01

Softwareversion = 2.003

SignedPackage = 0

[Softwarepackageinfo]

Packagename = Fred

Packagesize = 12345

FootprintSizeVolatile - 5000000

FootprintSizeNonVolatile = 25000000

SignedPackaged = 0

[ResourceAccessInfo]

URL^shttp://download.cisco.com/STB-Software/fred1001.bin.

Пример записи той же самой информации в кодированной форме:

[ DVB-STUB-HEADER • v1.0]

1a=4567:1b=Fred:1c=1.01:1d=2.003:2a=Fred:2b=12345:2c=5000000;2d=25000000;

2e^B0;3a^shttp^/download.cisco.com/STB-Softwaredred1001.bin.

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

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

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

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

Таблица 6 — Информация о типах протокола ResourceAccess

Приложение А (справочное)

Опции DHCPv4. необязательные для применения

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

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

Продолжение таблицы А. 1

Окончание таблицы А. 1

Семантика многоадресного транспортного протокола DVB SD&S

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

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

Таблица Б.1 — Версия протокола IP

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

Таблица Б.2 — Типы схем компрессирования

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

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

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

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

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

Схема DVB-MCAST URI

• В.1 Обзорная часть

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

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

• В.2 Базовая схема URI DVB-MCAST

Базовая схема 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-передачи. Этот элемент используется для поддержки источника muilicasl-рассылки (SSM).

• В.З Схема URI DVB-MCAST для DVBSTP

Базовая схема URI DVB-MCAST. определенная в разделе В.2. расширяется для обеспечения возможности поиска по ссылке конкретных элементов протокола DVBSTP — SP. РТ и сегментов. Идентификатор 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 ?paytoad^sdvbstp [&service-provider= ServiceProviderlD] [&dvbstp-payload^s DVBSTPPayloadID] [&segment= SegmentID] [#? dvb-cds- session-»d= Download-Session-ID]

= хост источник (для источника multicast передачи)

= multicast-адрес

= порт

= IP-адрес

= 2’2 HEXDIG; любое шестнадцатиричное число от 0x00 до ОхН

- 4*4 HEXDIG; любое шестнадцатиричное число от 0x0000 до Oxffff

Download-Session-ID^s Decimalstring.

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

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

• В.4 Схема URI DVB-MCAST для SAP

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

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

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

dvb-mcast// (src-hcst @ ) mcast-addr : port ?payk>ad^ssap (#? sdp-session-id^s Download-Session-ID]

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

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

УДК 621.397.132.129:006.354

Ключевые слова: DVB-IPTV, провайдер, DVBSTP. LMB. CDS, метаданные. DNS. домен. DHCP. HNED

Редактор Л. С. Зимипова Технический редактор В.Н. Прусакова Корректор М.И. Першина Компьютерная верстка ГД. Мухиной

Сдана в набор 28.10.2021. Подписано о печать 23.11.2021. Формат 60x84%. Гарнитура Ариал. Усл. печ. л. 3.26. Уч.-им. л. 2.64

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Сомано в единичном исполнении в ФГБУ «РСТз . 117418 Москва. Нахимовский пр-т. д. 31. к. 2.

www.gosbnfo.ru