ГОСТ Р 54994—2012
20
5.4.3.2.2 Объем данных, который может инкапсулироваться в каждом пакете UDP (и, следова-
тельно, в секции), ограничен максимальным размером дейтаграммы IP (65535 байтов для IPv4), минус
размер заголовка UDP. С целью устранения возможной сетевой фрагментации рекомендуется уста-
навливать максимальный размер дейтаграммы (секции) таким, что бы он не превышал размера макси-
мального модуля передачи (MTU), равного 1452 байта. При использовании дополнительных IP, UDPили
многоадресных версий протокола это значение должно быть соответствующим образом уменьшено.
Если размер секции установлен таким, что фрагментация происходит, любые конечные устрой-
ства, которые не поддерживают фрагментацию, не смогут получить полезную нагрузку SD&S. Поэтому
рекомендуется системным провайдерам в заголовке IP устанавливать сообщение DF («Не фрагмен-
тируйте»). При получении такого сообщения (если длина секции превысит установленный MTU сети)
маршрутизаторы возвратят сообщение ICMP «необходима фрагментация, но установлен флаг ее за-
прета (DF)». При получении таких сообщений системный провайдер может скорректировать размер
полезной нагрузки.
В соответствии со стандартом IETF [19] все хосты (узлы отравителя и получателя) должны обе-
спечивать прием дейтаграмм размером 576 байтов.
5.4.3.2.3 Использование поля ProviderID позволяет HNED фильтровать пакеты, не распаковывая
их. Рекомендуется использовать поле ProviderID только с записями открытия провайдера служб, когда
PayloadID — 0x01, так как процесс открытия гарантирует получение только многоадресных адресов.
5.4.3.2.4 Значение частоты повторения всех сегментов SD&S записи для провайдера служб не
должно приводить к превышению максимального времени цикла 30 с, определенного в 5.2.5 настоя-
щего стандарта.
5.4.4 Протокол для одноадресной поставки информации SD&S
При поставке информации SD&S в режиме «pull» для передачи данных между HNED и сервера-
ми SD&S должен использоваться протокол HTTP в соответствии с IETF [16]. При запросе домашним
сетевым оконечным устройством информации SD&S, HNED должен использовать следующий формат:
‘GET /dvb/sdns ‘ request ‘ HTTP/1.1’ CRLF
‘Host: ‘ host CRLF
где request = sp_discovery_request/service_discovery_request.
<request> используется для идентификации конкретного типа запроса. Предусмотрены два типа
запроса:
- sp_discovery_request для запроса информации для поиска провайдера служб;
- service_discovery_request для запроса информации для поиска предложения службы провайде-
ра служб.
Для запроса sp_discovery_request <хост> имеет IP-адрес сервера SD&S, полученного в соответ-
ствии с 5.2.7 настоящего стандарта.
Для запроса service_discovery_request <хост> имеет адрес, определенный в поле «Location of the
SP Discovery Record» в соответствии с 5.2.8.
Запрос может содержать другие поля заголовка, соответствующие IETF [16].
Детализированное описание применения протокола для одноадресной поставки информации
SD&S должно быть в соответствии с ETSI [12] (5.4.2).
5.4.4.1 По запросу открытия провайдера служб sp_discovery_request на HNED должна возвра-
титься запись открытия провайдера служб в соответствии с 5.2.8 настоящего стандарта (для одного
или всех провайдеров служб, работающих на сеть). Один из параметров запроса может принять значе-
ние ALL для запроса информации для поиска всех провайдеров служб или доменного имени опреде-
ленного провайдера служб с целью последующего запроса информации для поиска провайдера. В ре-
жиме «pull» записи, содержащие информацию для поиска провайдера служб (т.е. ID полезной нагрузки
0x01), не должны сегментироваться.
Форматы записей открытия должны быть в соответствии с ETSI [12] (5.4.2.1).
Запрос sp_discovery_request не должен выпускаться более одного раза на интервале максималь-
ного времени цикла.
5.4.4.2 По запросу открытия службы service_discovery_request на HNED должна возвратиться за-
пись открытия службы, как определено в 5.2.9 настоящего стандарта, содержащая описание службы,
предлагаемой конкретным провайдером служб. В состав запроса входят три обязательных параметра:
- доменное имя провайдера служб;
- тип предлагаемой службы (ID полезной нагрузки);
- ID сегмента.