RU2765121C1 - Способ организации потоковой передачи, способ предоставления информации идентификатора потоковой передачи, применение dns-сервера, устройство, компьютерная программа и машиночитаемый носитель - Google Patents

Abstract

Изобретение относится к области передачи данных. Технический результат заключается в обеспечении возможности организации потоковой передачи в сети, не требующей ручного управления идентификаторами потоковой передачи, используемыми в плоскости контроля. Устройство сконфигурировано для отправки сообщения-запроса на DNS-сервер, на котором сохранены записи, каждая из которых содержит идентификатор потоковой передачи первого вида, назначенный потоковой передаче, и отличный от него идентификатор потоковой передачи второго вида, назначенный соответствующей потоковой передаче, и указание предусмотренного типа, который использован или соответственно используется исключительно для этого вида записей, при этом сообщение-запрос содержит по меньшей мере один идентификатор потоковой передачи первого вида, который известен устройству, и предусмотренный тип, для получения от DNS-сервера сообщения-ответа, которое содержит идентификатор потоковой передачи второго вида, относящийся к потоковой передаче, и для использования полученного идентификатора потоковой передачи второго вида для подключения к соответствующей потоковой передаче. 5 н. и 15 з.п. ф-лы, 3 ил.

Description

Изобретение относится к способу организации потоковой передачи в сети TSN, в частности сети согласно IEEE 802.1. Кроме того, изобретение относится к способу предоставления информации идентификатора потоковой передачи, применению DNS-сервера, устройству, компьютерной программе и машиночитаемому носителю.

В рамках стандартизации IEEE технология Ethernet (см. IEEE 802) была расширена в рабочей группе AVB (Audio-Video-Bridging) механизмами для достижения гарантированного QoS (так называемого «Quality of Service»).

Чувствительный ко времени сетевой обмен данными (TSN) обозначают серию стандартов, которые, среди прочего, расширяют стандарт мостового соединения IEEE 802.1Q за счет механизмов передачи в реальном времени критически важных данных через сети Ethernet. Стандарты TSN включают, например, временную синхронизацию (IEEE 802.1AS-Rev), прерывание на уровне передачи кадров в пользу кадров с большим приоритетом (IEEE 802.1Qbu) и резервирование (IEEE 802.1Qca, IEEE 802.1Qcc), а также другие стандарты.

В контексте AVB и TSN качество должно быть гарантировано так называемыми потоковыми передачами. Потоковая передача - это защищенное коммуникационное соединение. Перед фактической передачей данных через потоковую передача происходит регистрация и резервирование сетевых ресурсов, чтобы обеспечить без потерь передачу кадров данных в реальном времени и своевременную доставку. Резервирование ресурсов для потоковой передачи может выполняться, в частности, с помощью так называемого протокола резервирования потоковой передачи (SRP). SRP рассматривается, например, в документе «Stream Reservation Protocol», автор Леви Пирсон, AVnu Alliance Best Practices, 3 ноября 2014 г. (2014-11-03), страницы 1-21, XP055449688.

Направление потоковой передачи данных определено в модели потоковой передачи TSN. Передающая сторона или источник в этом случае упоминается как «говорящий», а принимающая сторона или приемник упоминается как «слушатель». С одной стороны, можно реализовать, что один «говорящий» отправляет данные двум или более «слушателям» одновременно, а с другой стороны, два или более «слушателя» могут одновременно посылать ровно одному «говорящему».

Приложения идентифицируют отдельные потоковые передачи в чувствительных ко времени сетях, точнее в плоскости контроля TSN (TSN Control Plane), с помощью связанных идентификаторов, в частности, так называемых ID потоковой передачи (Stream ID). С точки зрения TSN это битовые строки длиной 64 бита без внутренней структуры.

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

В архитектуре TSN ID потоковой передачи для идентификации потоковой передачи намеренно выбираются сравнительно короткими - всего 64 бита. Это связано с тем, что по техническим причинам все ID потоковой передачи должны быть известны во всех узлах чувствительной ко времени сети, в частности, во всех мостах TSN в сети TSN-LAN, и в каждом случае более длинные ID потоковой передачи быстро превысят объем памяти.

Сравнительно небольшая длина означает, что ID потоковой передачи подлежат «управлению с дефицитом».

Одним из способов обхода «управления с дефицитом» ID потоковой передачи в сети является ручное управление. Оно осуществляется, например, ведением таблицы, например таблицы Excel. Однако, это связано с несоизмеримой затратностью.

US 2013/282453 A1 раскрывает систему и способ потоковой передачи мультимедиа.

Автоматическое управление ID потоковой передачи во время работы также было бы очень желательным, в частности, для того, чтобы иметь возможность добавлять новые приложения TSN в сеть просто посредством подхода «подключи и работай» (Plug and Play), без необходимости обновления общего планирования всех ID потоковой передачи.

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

Эта цель достигается с помощью способа организации потоковой передачи в сети TSN, в частности в сети согласно IEEE 802.1, в котором

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

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

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

Кроме того, цель изобретения достигается устройством, которое спроектировано и/или сконфигурировано

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

- для получения от DNS-сервера сообщения-ответа, которое содержит идентификатор потоковой передачи второго вида, назначенный потоковой передаче, и

- для использования полученного идентификатора потоковой передачи второго вида для подключения к соответствующей потоковой передаче.

Другими словами, настоящее изобретение предусматривает использование двух разных видов идентификаторов потоковой передачи. Это дает возможность абонентам или приложению(ям) использовать вид идентификатора потоковой передачи, который отличается от идентификатора потоковой передачи, используемого в плоскости контроля. В частности, таким образом, абонент или приложение (приложения) могут использовать идентификатор, который значительно длиннее, чем идентификатор потоковой передачи, используемый в плоскости контроля TSN ID потоковой передачи, который имеет длину «всего» 64 бита. Кроме того, согласно изобретению, осуществляется доступ к службе имен, чтобы назначить идентификаторы потоковой передачи абонента или приложения идентификаторам потоковой передачи из плоскости контроля или для нее.

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

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

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

Записи, хранящиеся на DNS-сервере, предпочтительно являются ресурсными записями, причем ресурсные записи, в частности, являются частью файла, хранящегося на DNS-сервере.

Согласно изобретению, вместо типа, который ранее известен из предшествующего уровня техники, например, вместо тех типов, которые определены в RFC 1035 для ресурсных записей (RR), например «A», «TXT», «PTR» »,«NS»,«SOA» или других типов в соответствии с другими стандартами, в частности с другими RFC, используется новый тип, специально предназначенный для предоставления идентификаторов потоковой передачи как часть службы имен. Например, это можно назвать типом «TSN». Это предпочтительно 16-битный тип. Точное значение типа может быть удобно указано в рамках стандартизации, в частности, Инженерным Советом Интернета (IETF) или Администрацией Адресного Пространства Интернета (IANA).

Следует отметить, что RFC относится к Request for Comments of the Internet Engineering Task Force Group (IETF). RFC 1035 доступен, например, по адресу https://tools.ietf.org/html/rfc10345.

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

В частности, по сравнению со случаем, когда информация о назначении идентификаторов потоковой передачи первого и второго вида депонируется в ресурсных записях типа «TXT», как это предлагается в заявке на европейский патент с номером EP 17187473.8, которая также относится к настоящему заявителю, требуемое обновление информации TSN в DNS упрощается, поскольку требование теперь относится достаточно конкретно к информации TSN, а не к неопределенным ресурсным записям TXT. Поскольку ресурсные записи TXT используются для многих различных приложений (см., в частности, RFC 6763), а операции DNS-запроса могут фильтроваться максимум по типу ресурсной записи, приложения TSN могут получать большее количество ресурсных записей TXT в качестве ответа, которые после этого сначала необходимо проверить для того, что установить, где и как находится ресурсная запись TXT, содержащая информацию TSN. В частности, на устройствах ввода-вывода может оказаться, что необходимые для этого ресурсы недостаточны или требуют дорогостоящего оборудования.

Согласно настоящему изобретению, тип, специально предназначенный для информации TSN, в частности тип ресурсной записи, обеспечивает то, что в ответ на запрос принимается только специфическая для TSN информация. В частности, возвращаются только «короткие» ресурсные записи TSN, и никакие другие ресурсных записей TXT, размер которых может достигать до 64 КБ на ресурсную запись.

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

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

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

Кроме того, подход в соответствии с изобретением позволяет в процессе создания приложения осуществлять доступ только к одному или нескольким идентификаторам потоковой передачи первого вида, а привязку для ссылки на идентификатор потоковой передачи второго вида производить практически только «в последнюю минуту» с использованием DNS-сервера. Это позволяет разделить с точки зрения организации и времени процессы (планирования) для идентификаторов потоковой передачи первого и второго видов. Следовательно, идентификаторы первого вида могут быть указаны уже до того, как будут указаны окончательные идентификаторы второго вида, которые должны использоваться в плоскости контроля TSN.

Соответственно, может быть предусмотрено, что по меньшей мере один абонент потоковой передачи может отправлять сообщение-запрос только после того, как было завершено создание приложения, в котором участвует абонент потоковой передачи, например, путем загрузки приложения на устройство ввода-вывода из средства разработки.

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

Под службой имен следует понимать, в частности, службу, которая присваивает (числовые) IP-адреса, например IP-адреса IPv4 или IPv6, имена, в частности доменные имена, устройствам, компьютерам, службам и подобному. Система доменных имен (DNS) является одной из таких служб, основная задача которой обычно состоит в том, чтобы отвечать на запросы о разрешении имен, то есть перевод имен в адреса, в частности, в IP-сетях. Стандарты, связанные с DNS, - это, в частности, RFC 1034 и RFC 1035. Сервер, предоставляющий службу имен, также называется сервером службы имен (Name server); в случае DNS он также называется DNS-сервером.

DNS-сервер, используемый согласно изобретению, также может быть локальным DNS-сервером. Несущественно, «откуда» DNS-сервер предоставляет свои услуги; услуга может быть предоставлена где угодно, если есть доступность IP (IP-соединение) с предоставляющим услуги DNS-сервером(ами). «Локальный» может быть, например, в той же подсети или где-нибудь в облаке, например, в компании. Эта свобода или независимость - важная черта службы имен, в частности DNS.

Передача данных через потоковую передачу осуществляется в сети TSN, при этом под этим понимается сеть, которая отвечает одному или нескольким стандартам для чувствительной ко времени сети (TSN), в частности, включает один или несколько узлов, совместимых с TSN, например коммутаторы и/или мосты. Стандарты TSN включают, например, временную синхронизацию (IEEE 802.1AS-Rev), прерывание на уровне передачи кадров в пользу кадров с большим приоритетом (IEEE 802.1Qbu) и резервирование (IEEE 802.1Qca, IEEE 802.1Qcc), а также другие стандарты.

Сеть предпочтительно представляет собой промышленную сеть, в частности установку промышленной автоматизации.

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

Что касается резервирования, предназначенного для потоковой передачи, в принципе доступны различные варианты, ранее известные из уровня техники. IEEE 802.1Qcc, например, описывает как минимум три подхода для этого, в частности, так называемую «полностью децентрализованную модель», «полностью централизованную модель», используемую, например, для PROFINET IRT, и гибридную модель «централизованная сеть, децентрализованный пользователь».

Процедура резервирования зависит, среди прочего, от соответствующего протокола резервирования, в частности, в соответствии с IEEE 802.1Qcc. Примером протокола резервирования, который можно использовать, является MSRP.

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

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

Само собой разумеется, что только одна или несколько потоковых передач могут быть организованы в сети посредством выполнения способа согласно изобретению.

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

Два или более абонента потоковой передачи могут быть представлены, например, контроллером, например ПЛК, и одним или несколькими датчиками установки автоматизации, которые передают собранные данные измерений в ПЛК через потоковую передачу. Если присутствует несколько датчиков, которые используют потоковую передачу для отправки в ПЛК, то существует сценарий с несколькими говорящими и только одним слушателем. Если данные, например значения управления, предназначены для отправки от контроллера, в частности, ПЛК, к одному или нескольким исполнительным механизмам, тогда будет реализован сценарий с одним говорящим и одним или несколькими слушателями.

Абоненты потоковой передачи могут быть абонентами или частями распределенного приложения. Датчики/исполнительные механизмы и ПЛК могут образовывать, например, части распределенного «контроллера» приложения TSN.

Следует отметить, что два или более абонента потоковой передачи могут быть разными (терминальными) устройствами в сети, но они также могут находиться на (терминальном) устройстве. Возможно, например, что два или более приложений или частей приложения, которые хотят участвовать в потоковой передаче для работы на устройстве, которое содержит мост - при необходимости, только программно-реализованный мост - или функцию моста. Это может иметь место, например, в области виртуализации. Только в качестве иллюстрации можно упомянуть виртуальный ЦП и интерфейс пользователя (HMI) на компьютере.

Идентификатор потоковой передачи первого вида предпочтительно представляет собой имя потоковой передачи, используемое по меньшей мере одним абонентом потоковой передачи для идентификации потоковой передачи, предпочтительно имя домена, назначенное потоковой передаче, в частности имя владельца в соответствии с RFC 1034, назначенное потоковой передаче.

Идентификатор потоковой передачи первого вида может быть полностью определенным доменным именем (FQDN), в частности, в контексте RFC 7719.

Идентификатор потоковой передачи первого вида также предпочтительно используется пользователями.

Идентификатор потоковой передачи первого вида, переданный от по меньшей мере одного абонента потоковой передачи к DNS-серверу с сообщением-запросом, чтобы запросить идентификатор потоковой передачи второго вида, известен по меньшей мере одному абоненту потоковой передачи. Он может быть или мог быть передан по меньшей мере одному абоненту потоковой передачи любым способом, например, посредством уведомления от центрального пункта. Идентификатор потоковой передачи первого вида также может быть сгенерирован абонентом потоковой передачи. Только в качестве пояснения в этом контексте может быть сделана ссылка на заявку с номером EP 17187473.8, которая относится к настоящему заявителю и раскрывает соответствующий способ.

Идентификатор потоковой передачи второго вида - это, в частности, тот, который используется в плоскости приложения TSN (TSN Application Plane).

Идентификатор потоковой передачи второго вида может быть идентификатором потоковой передачи, который используется сетью, в частности, ID потоковой передачи, используемый в плоскости контроля (TSN) сети, предпочтительно в соответствии с IEEE 802.1Qat.

Идентификаторы потоковой передачи второго вида также предпочтительно являются 64 битными. Это гарантирует, что объем памяти в узлах, например мостах и/или коммутаторах сети, не будет излишне загружен или перегружен.

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

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

Другой вариант осуществления характеризуется тем, что сообщение-запрос отправляется в форме DNS-запроса (DNS-Query). Альтернативно или дополнительно может быть предусмотрена отправка сообщения-ответа в форме DNS-запроса.

Устройство согласно изобретению сконструировано соответствующим образом и/или сконфигурировано в предпочтительном варианте.

Существуют различные варианты того, как записи с присвоением идентификаторов потоковой передачи первого вида идентификаторам второго вида помещаются на DNS-сервер - например, через DNS-обновления.

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

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

Устройство согласно изобретению может быть соответствующим образом спроектировано и/или сконфигурировано для отправки на DNS-сервер сообщений обновления, которые содержат запись для DNS-сервера, содержащую, по меньшей мере, один идентификатор потоковой передачи первого вида и, по меньшей мере, один идентификатор потоковой передачи второго вида, и указание предусмотренного типа для потоковой передачи, в частности, в форме DNS-обновления (DNS UPDATE), предпочтительно в соответствии с RFC 2163.

Идентификатор потоковой передачи первого вида из сообщения обновления предпочтительно предоставляется каноническим именем в соответствии с RFC 7719.

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

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

Запись из сообщения обновления содержит не только идентификаторы потоковой передачи двух видов и указание предусмотренного типа, но предпочтительно также класс и/или указание TTL и/или предпочтительно 64-битную область RDATA.

Запись из сообщения обновления также предпочтительно компонуется так, чтобы идентификатор потоковой передачи первого вида был каждый раз в начале, а за ним следовали тип, класс, указание TTL и область RDATA.

В дополнительном предпочтительном варианте идентификатор потоковой передачи второго вида указывается в области RDATA записи, при этом, в частности, идентификатор потоковой передачи второго вида указывается первым старшим октетом, причем самый старший бит считается как бит 0. Это соответствует так называемому сетевому порядку. Подсчет самого старшего бита как 0 соответствует соглашению IETF.

Сообщение обновления особенно предпочтительно отправляется на DNS-сервер в форме DNS-обновления, в частности, согласно RFC 2163.

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

Записи, которые предоставляются на DNS-сервере, и каждая из которых связывает идентификатор потоковой передачи первого вида, назначенный потоковой передаче, и идентификатор потоковой передачи второго вида, который отличается от указанного идентификатора потоковой передачи первого вида, назначенного соответствующей потоковой передаче, и которые содержат указание предусмотренного типа, используемого исключительно для этого типа записей, предпочтительно характеризуются той же структурой, которая в данном случае указывается для записей из сообщений обновления, то есть предпочтительно дополнительно содержат класс и/или указание TTL и/или область RDATA, имеющую размер предпочтительно 64 бита, и предпочтительно скомпонованы так, чтобы идентификатор потоковой передачи первого вида был каждый раз в начале, а за упомянутым идентификатором потоковой передачи следовали тип, класс, указание TTL и область RDATA, и в которой, в частности, идентификатор потоковой передачи второго вида предпочтительно указывается в соответствии с тем, что известно как сетевой порядок.

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

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

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

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

Машиночитаемый носитель может быть, например, CD-ROM или DVD, USB или флэш-памятью. Следует отметить, что машиночитаемый носитель не предназначен для обозначения исключительно физического носителя, скорее, такой носитель также может быть доступен, например, в форме потока данных и/или сигнала, который представляет поток данных.

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

ФИГ. 1 - схематическое изображение двух терминальных устройств в промышленной сети установки автоматизации, которые принимают информацию идентификатора потоковой передачи от DNS-сервера;

ФИГ. 2 - схематическое изображение передачи информации идентификатора потоковой передачи на сервер службы имен; и

ФИГ. 3 - терминальные устройства по фиг. 1, в котором одно терминальное устройство осуществления DNS UPDATE (DNS обновление) для DNS-сервера.

ФИГ. 1 показывает схематическое частичное изображение промышленной сети, в частности установки автоматизации, не изображенной более подробно на фигурах.

Сеть включает множество абонентов, подключенных через множество сетевых узлов в виде TSN-совместимых коммутаторов, которые не показаны на сильно упрощенном изображении по фиг. 1. Только два абонента 1, 2 из множества абонентов сети показаны на фиг. 1, исключительно в качестве иллюстрации. Левый абонент на фиг. 1 в данном случае представляет собой терминальное устройство 1, которое обеспечивается программируемым логическим контроллером (ПЛК) 1 установки автоматизации. Дополнительный абонент реализован как устройство 2 ввода-вывода установки автоматизации, причем упомянутое устройство ввода-вывода содержит или подключено к исполнительному механизму, который не показан.

Во время работы установки автоматизации ПЛК 1 циклически передает управляющие значения на устройство 2 ввода-вывода достаточно известным образом, а исполнительный механизм циклически влияет на технический процесс, который далее не изображен, в соответствии с управляющими значениями.

Передача данных между ПЛК 1 и устройством 2 ввода-вывода должна происходить в реальном времени. В частности, необходимо гарантировать, что данные, покидающие ПЛК 1, поступают на устройство 2 ввода-вывода без потерь в каждом случае по истечении установленного времени. Это возможно в результате организации потоковой передачи TSN, то есть защищенного коммуникационного соединения между двумя абонентами 1, 2.

ПЛК 1, отправляющий данные, является говорящим (отправителем), а устройство 2 ввода-вывода - слушателем (получателем).

Процесс управления, который требует обмена данными между ПЛК 1 и устройством 2 ввода-вывода в реальном времени с гарантированным качеством обслуживания (QoS), также можно рассматривать как распределенное приложение TSN, при этом часть приложения выполняется на ПЛК 1, а часть на устройстве 2 ввода-вывода. На фиг. 1 две части приложения TSN «контроллера» обозначены блочными элементами, имеющими ссылочные номера 3 или 4.

Приложения идентифицируют отдельные потоковые передачи в чувствительных ко времени сетях (TSN), точнее в «плоскости контроля TSN», с помощью назначенных идентификаторов потоковой передачи, в частности так называемых ID потоковой передачи. С точки зрения TSN это битовые строки длиной 64 бита без внутренней структуры.

Чтобы два или более абонента потоковой передачи 1, 2 могли подключаться к общей потоковой передаче с использованием одного и того же ID потоковой передачи, абонентам 1, 2 необходимо знать идентификатор, связанный с потоковой передачей для плоскости контроля, то есть ID потоковой передачи.

В архитектуре TSN ID потоковой передачи для идентификации потоковой передачи намеренно выбираются сравнительно короткими - всего 64 бита. Это связано с тем, что по техническим причинам ID потоковой передачи для всех установленных в сети потоковых передач должны быть известны во всех задействованных узлах, например коммутаторах. Если бы использовались более длинные ID потоковой передачи, объем памяти в узлах был бы быстро исчерпан или превышен.

Небольшая длина использовавшихся до настоящего времени ID потоковой передачи обуславливала «управлению с дефицитом», что всегда требует тщательного сравнения занятости. Этот недостаток можно обойти с помощью ручного управления ID потоковой передачи, создав таблицу Excel. Однако это связано с несоизмеримой затратностью. Автоматическое управление ID потоковой передачи также было бы очень желательным, в частности, для того, чтобы иметь возможность добавлять новые приложения 3,4 TSN просто посредством подхода «подключи и работай» (Plug and Play), без необходимости обновления общего планирования всех ID потоковой передачи.

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

В частности, для идентификации потоковой передачи используют два разных вида идентификаторов потоковой передачи, а именно идентификатор потоковой передачи первого вида, который в данном случае предпочтительно является именем потоковой передачи, используемым двумя абонентами 1, 2 потоковой передачи для идентификации потоковой передачи, более конкретно назначенное потоковой передаче имя владельца в соответствии с RFC 1034, которое может характеризоваться длиной до 2040 бит. Имя владельца потоковой передачи известно каждому из двух абонентов потоковой передачи 1, 2. На фиг.1 имя владельца потоковой передачи, известное абонентам 1, 2, обозначено схематично с помощью элемента блока, снабженного ссылочной позицией 5.

Кроме того, используется идентификатор потоковой передачи второго вида, который представляет собой ID потоковой передачи длиной 64 бита, согласно IEEE 802.1Qat, который используется в плоскости контроля сети TSN для идентификации потоковой передачи.

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

С другой стороны, приложение может использовать длинные имена потоковой передачи, то есть в плоскости приложений TSN. Для этого требуется их хранение только на отдельных устройствах 1, 2, но не на всех задействованных узлах. Таким образом, в устройствах 1, 2 имеется необходимое пространство памяти для обработки только нескольких, но при этом более длинных идентификаторов. Это позволяет намеренно использовать пространство имен «тонко» и элегантно избегать конфликтов. Этот принцип известен, например, из системы доменных имен (DNS) (см., в частности, RFC 1034 и 1035).

Более длинные идентификаторы потоковой передачи первого вида для приложений и более короткие идентификаторы потоковой передачи второго вида для TSN назначаются, согласно настоящему изобретению, путем доступа к серверу 6 службы имен. В описанном примерном варианте осуществления используется DNS-сервер 6, который изображен на фиг. 1 только схематично простым блочным элементом.

Чтобы назначение с использованием DNS-сервера 6 было возможно, последний сохраняет информации идентификатора потоковой передачи в дополнение к информации, необходимой для обычной службы имен. Информация идентификаторе потоковой передачи, дополнительно доступная на DNS-сервере 6, показана на фиг. 1 с помощью элемента, снабженного ссылочным позицией 7 на DNS-сервере 6.

В описанном примерном варианте осуществления DNS-сервер 6 конкретно хранит файл идентификатора потоковой передачи, содержащий дополнительную информацию. Указанный файл может быть предоставлен, например, в форме файла зоны, в частности, согласно RFC 1034 и 1035, или в форме файла, созданного на основе такого файла, или же может иметь другой формат.

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

Ресурсные записи (RR) нового типа «TSN» построены следующим образом:

1. Владелец: доменное имя, см. RFC 1034

2. Тип (16 бит): «TSN» - точное значение целесообразно присваивается в рамках стандартизации Инженерным Советом Интернета (IETF) или Администрацией Адресного Пространства Интернета (IANA).

3. класс (16 бит): «IN», см. RFC 1034.

4. TTL (32-бита): как определено в RFC 1034.

5. RDATA: 64-битный ID потоковой передачи TSN (идентификатор потоковой передачи) в так называемом сетевом порядке, то есть с первым старшим октетом, причем старший бит считается как бит 0 (!) в соответствии с соглашением IETF.

Следует отметить, что новые поля по сравнению с ресурсными записями, ранее известными в предшествующем уровня техники, выделены жирным шрифтом в этом списке. Ранее известные записи ресурсов следуют, например, из RFC 1025.

Пример ресурсной записи в этой форме:

rocket-launcher.coyote.acme.corp. TSN IN feadbeefcafebabe

с именем владельца потоковой передачи «rocket-launcher.coyote.acme.corp», выбранным только в качестве иллюстрации, в форме полностью определенного доменного имени (FQDM) и 64-битного ID потоковой передачи, также выбранных исключительно посредством иллюстрация как «deadbeefcafebabe» в шестнадцатеричной системе счисления в области RDATA ресурсной записи.

Следует отметить, что в приведенном выше примере не показано значение TTL («Время жизни»). Это может быть 600, например, что соответствует TTL в 10 минут, или может быть другим. Это значение имеет значение только для DNS-кеширования, но не для TSN.

Способ, в соответствии с которым информация идентификатора потоковой передачи была предоставлена в DNS, более подробно поясняется далее.

Для узнавания ID потоковой передачи, относящегося к потоковой передаче, и ПЛК 1, и устройство 2 ввода-вывода отправляют сообщение-запрос 8 на DNS-сервер 6. Это осуществляется, в частности, в форме DNS-запроса. На фиг. 1 сообщение-запрос или DNS-запрос обозначены как элемент блока, снабженный ссылочной позицией 8 рядом со стрелкой, указывающей на DNS-сервер 6.

Каждое сообщение-запрос 8 содержит идентификатор потоковой передачи первого вида, который известен ПЛК 1 и устройству 2 ввода-вывода 2, в форме имени 5 владельца потоковой передачи, и предусмотренный тип «TSN».

Для имени потоковой передачи, указанного выше в качестве примера, запрос будет выглядеть:

DNS-ЗАПРОС:

rocket-launcher.coyote.acme.corp. ТSN IN

Следует отметить, что в данном случае ПЛК 1 и устройство 2 ввода-вывода знают одно и то же имя 5 владельца потоковой передачи как идентификатор потоковой передачи первого вида. Однако, это не является обязательным. Более того, разные абоненты также могут знать разные идентификаторы потоковой передачи первого вида для потоковой передачи. Кроме того, существует несколько ресурсных записей для ID потоковой передачи в качестве идентификатора потоковой передачи второго вида, в частности, одна ресурсная запись для каждого идентификатора потоковой передачи первого вида.

В ответ на DNS-запрос и ПЛК 1, и устройство ввода-вывода получают от DNS-сервера 6 сообщение-ответ, в данном случае также в форме DNS-запроса. Сообщение-ответ показано на фиг. 1 с помощью элемента, снабженного ссылочной позицией 9 рядом со стрелкой, указывающей от DNS-сервера 6 к ПЛК 1 или устройству ввода-вывода 2.

В описанном примерном варианте осуществления каждый из ПЛК 1 и устройства 2 ввода-вывода содержат модуль 10 ID потоковой передачи, предназначенный для отправки сообщений-запросов 8 и приема сообщений-ответов 9, то есть DNS-запросов. Модуль 10 ID потоковой передачи разработан и/или сконфигурирован для этой цели соответствующим образом. Модуль 10 ID потоковой передачи может быть реализован программно, например, программное обеспечение может работать, в частности, на обычном оборудовании устройств 1, 2, которое присутствует в любом случае, или же может быть реализовано чисто аппаратно, в частности, посредством аппаратных средств, специально предназначенных для модуля 10, или может содержать комбинацию программных и аппаратных средств, в частности аппаратных средств, специально предназначенных для модуля 10.

Сообщение-ответ 9, полученное от DNS-сервера 6, содержит ID потоковой передачи, связанный с потоковой передачей. Оно извлекается из сообщения-ответа 9 модулем 10 ID потоковой передачи, и впоследствии ПЛК 1 и устройство 2 ввода-вывода могут зарегистрироваться в потоковой, используя назначенный идентификатор потоковой передачи, и данные могут быть переданы из ПЛК 1 к устройству 2 ввода-вывода посредством потоковой передачи в реальном времени. Регистрация в потоковой передаче также может выполняться с помощью модуля 10 ID потоковой передачи, который для этого соответствующим образом компонуется и/или конфигурируется.

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

Предпочтительно, информация идентификатора потоковой передачи в форме стандартизованного файла зоны, в частности, согласно RFC 1034 и RFC 1035, была предоставлена средством разработки, которое использовалось для установки сети, в которую включены устройства 1, 2, изображенные на фиг. 1. Файл зоны был предоставлен с помощью центрального средства разработки и впоследствии импортирован DNS-сервером 6.

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

В качестве примера также возможна прямая передача DNS-данных с использованием операции DNS-обновления (DNS UPDATE), в частности, в соответствии с RFC 2136 «Динамические обновления в системе доменных имен (DNS UPDATE)».

В качестве альтернативы или в дополнение к используемому средству разработки файл, содержащий информацию об идентификаторе потоковой передачи, также может быть предоставлен центральным онлайн-средством и впоследствии передан на сервер 6 службы имен, в частности, с помощью операции DNS UPDATE в соответствии с RFC 2136.

Фиг. 2 схематично изображает онлайн-средство в виде блочного элемента, снабженного ссылочной позицией 12, а стрелка, указывающая от упомянутого онлайн-средства к DNS-серверу 6, используется для указания DNS-обновления.

В качестве альтернативы того, что информация идентификатора потоковой передачи передается на DNS-сервер 6 от центрального пункта, информация также может быть передана или может непрерывно передаваться на сервер 6 децентрализовано участниками сети, которые являются абонентами потоковой передачи, аналогично посредством DNS-обновления. В качестве примера может быть так, что идентификаторы указанного вида, назначенные потоковой передаче, передаются или могут быть переданы по меньшей мере соответствующему инициатору потоковой передачи, то есть абоненту, объявляющему или инициирующему потоковую передачу в сети, не через DNS-сервер 6, а другим путем.

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

Это может быть осуществлено, в частности, посредством DNS UPDATE, например, согласно RFC 2136. Если каждый инициатор потоковой передачи передает данные на сервер службы имен таким образом, упомянутые данные могут быть получены другими абонентами.

Процесс DNS UPDATE со стороны инициатора потоковой передачи схематично показан на фиг. 3. В этом случае идентичные компоненты или элементы имеют идентичные ссылочные позиции.

DNS UPDATE, выполняемое ПЛК 1, который является инициатором потоковой передачи, изображается элементом блока, снабженным ссылочной позицией 13, рядом со стрелкой, показывающей от ПЛК 1 к DNS-серверу 6. DNS UPDATE для (децентрализованного) предоставления TSN или информации о потоковой передаче в службе имен обрабатывается модулем 10 ID потоковой передачи ПЛК 1, который должным образом спроектирован и/или сконфигурирован. Поскольку ПЛК 1 уже знает ID потоковой передачи, ему больше не требуется формировать DNS-запрос для его запроса, как в сценарии, показанном на фиг. 1.

Однако, устройство 2 ввода-вывода выполняет DNS-запрос - точно так же, как в сценарии, показанном на фиг. 1. В этом отношении можно сделать ссылку на приведенное выше описание.

Следует отметить, что потоковая передача в принципе может быть инициирована либо говорящим, либо слушателем, то есть инициатор потоковой передачи может быть представлен говорящим или слушателем. В ситуациях, когда несколько слушателей получают данные только от одного говорящего или когда несколько говорящих отправляют данные только одному слушателю, «один» абонент, то есть один говорящий, у которого есть несколько слушателей, или один слушатель, для которого есть несколько говорящих, в каждом случае может быть инициатором потоковой передачи.

Независимо от того, как информация об идентификаторах потоковой передачи была предоставлена на DNS-сервере 6, справедливо, что использование нового ТИПА записей, который был введен специально для этой цели, в частности ресурсных записей, предоставляет возможность особенно простого обновления - в особенности по сравнению с информацией об идентификаторе потоковой передачи, хранящейся в ресурсных записях типа TXT.

Требуемое обновление информации TSN упрощается, потому что требование теперь относится достаточно конкретно к информации TSN, а не к неопределенным ресурсным записям TXT. Более того, никаких дополнительных поддоменов, специфичных для TSN, не требуется.

Обновление может иметь, например, следующий вид:

DNS UPDATE:

ЗОНА:

coyote.acme.corp. SOA IN

НЕОБХОДИМЫЕ УСЛОВИЯ: --

(Пустая область RDATA сигнализирует о том, что еще нет требования или намерения для существования RRset для TSN).

rocket-launcher.coyote.acme.corp. TSN IN (пусто)

ОБНОВЛЕНИЯ:

rocket-launcher.coyote.acme.corp. TSN IN deadbeefcafebabe

Дополнительный лист:

--

Запись из сообщения обновления, соответственно, может содержать не только идентификаторы потоковой передачи двух видов и указание предусмотренного типа, но также класс и/или указание TTL и/или область RDATA, имеющую размер предпочтительно 64 бита. Запись может быть скомпонована, например, так, что идентификатор потоковой передачи первого вида каждый раз находится в начале, а за ним следует тип, класс, указание TTL и область RDATA с ID потоковой передачи. Примером этого является «rocket-launcher.coyote.acme.corp. TSN IN Deadbeefcafebabe».

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

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

DNS-ЗАПРОС:

rocket-launcher.coyote.acme.corp. TSN IN

Ответная или ответные ресурсные записи TSN содержат искомый один или несколько ID потоковой передачи.

Решение, согласно изобретению, дополнительно делает возможным в процессе создания приложения осуществлять доступ только к одному или нескольким идентификаторам потоковой передачи первого вида, а привязку для ссылки на идентификатор потоковой передачи второго вида производить практически только «в последнюю минуту» с использованием сервера службы имен. Это позволяет разделить с точки зрения организации и времени процессы (планирования) для идентификаторов потоковой передачи первого и второго видов. Следовательно, идентификаторы первого вида могут быть указаны уже до того, как будут указаны окончательные идентификаторы второго вида, которые должны использоваться в плоскости контроля TSN.

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

В качестве примера, само собой разумеется, что хотя на фигурах 1 и 3 показаны только два абонента потоковой передачи исключительно в качестве иллюстрации, естественно, что любое количество дополнительных абонентов потоковой передачи может зарегистрироваться в потоковой передаче после того, как они запросили ID потоковой передачи на DNS-сервере 6.

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

Claims (26)

1. Способ организации потоковой передачи в сети TSN, в котором

- по меньшей мере, один абонент (1, 2) потоковой передачи, желающий отправить данные через потоковую передачу по меньшей мере одному (1, 2) дополнительному абоненту потоковой передачи и/или желающий получать данные через потоковую передачу по меньшей мере от одного дополнительного абонента (1, 2) потоковой передачи, отправляет сообщение-запрос (8) на DNS-сервер (6), на котором сохранены записи, каждая из которых содержит идентификатор потоковой передачи первого вида, назначенный потоковой передаче, и отличный от него идентификатор потоковой передачи второго вида, назначенный соответствующей потоковой передаче, и указание предусмотренного типа, который использован или соответственно используется исключительно для этого вида записей, при этом сообщение-запрос (8) содержит по меньшей мере один идентификатор потоковой передачи первого вида, который известен упомянутому по меньшей мере одному абоненту (1, 2) потоковой передачи, и упомянутый предусмотренный тип,

- упомянутый по меньшей мере один абонент (1, 2) потоковой передачи получает от DNS-сервера (6) сообщение-ответ (9), которое содержит идентификатор потоковой передачи второго вида, относящийся к потоковой передаче, и

- упомянутый по меньшей мере один абонент (1, 2) потоковой передачи регистрируется в потоковой передаче с использованием полученного идентификатора потоковой передачи.

2. Способ по п.1, отличающийся тем, что идентификатором потоковой передачи первого вида является имя потоковой передачи, используемое упомянутым по меньшей мере одним абонентом (1, 2) потоковой передачи для идентификации потоковой передачи, и/или идентификатором потоковой передачи второго вида является ID потоковой передачи, используемое сетью для идентификации потоковой передачи.

3. Способ по п.1 или 2, отличающийся тем, что размер идентификатора потоковой передачи первого вида, указанного в битах, превышает размер идентификатора потоковой передачи второго вида, указанного в битах.

4. Способ по любому из пп. 1-3, отличающийся тем, что сообщение-запрос (8) отправляют в форме DNS-запроса и/или сообщение-ответ (9) отправляют в форме DNS-запроса.

5. Способ по любому из пп. 1-4, отличающийся тем, что записи, хранящиеся на DNS-сервере (6), являются ресурсными записями, различающимися по предусмотренному типу.

6. Способ по любому из пп. 1-5, отличающийся тем, что по меньшей мере один дополнительный абонент (1, 2) потоковой передачи отправляет на DNS-сервер (6) по меньшей мере одно сообщение (13) обновления, которое содержит запись для DNS-сервера (6), которая содержит по меньшей мере один идентификатор потоковой передачи первого вида и по меньшей мере один идентификатор потоковой передачи второго вида для потоковой передачи и указание предусмотренного типа.

7. Способ по любому из пп. 1-6, отличающийся тем, что центральный пункт отправляет DNS-серверу (6) по меньшей мере одно сообщение (13) обновления, которое содержит запись для DNS-сервера (6), которая содержит по меньшей мере один идентификатор потоковой передачи первого вида и по меньшей мере один идентификатор потоковой передачи второго вида для потоковой передачи и указание предусмотренного типа.

8. Способ по п.6 или 7, отличающийся тем, что запись из сообщения (13) обновления содержит, помимо идентификаторов потоковой передачи двух видов и указания предусмотренного типа, также класс, и/или указание TTL, и/или предпочтительно 64-битную область RDATA.

9. Способ по любому из пп. 6-8, отличающийся тем, что запись из сообщения (13) обновления сформирована таким образом, что идентификатор потоковой передачи первого вида соответственно находится в начале, а за ним следует тип, класс, индикатор TTL и область RDATA.

10. Способ по любому из пп. 6-9, отличающийся тем, что идентификатор потоковой передачи второго вида указывается в области RDATA записи.

11. Способ по любому из пп.6-10, отличающийся тем, что сообщение (13) обновления отправляют на DNS-сервер (6) в форме DNS UPDATE.

12. Способ по любому из пп. 1-11, отличающийся тем, что упомянутый по меньшей мере один абонент потоковой передачи является абонентом распределенного приложения.

13. Способ по любому из пп. 1-12, отличающийся тем, что сеть содержит один или несколько узлов, а идентификатор потоковой передачи второго вида хранится в одном или нескольких узлах сети.

14. Способ предоставления информации идентификатора потоковой передачи, в котором по меньшей мере один файл (11) идентификатора потоковой передачи предоставляется на DNS-сервере (6), при этом файл (11) идентификатора потоковой передачи содержит записи, каждая из которых содержит идентификатор потоковой передачи первого вида, назначенный потоковой передаче, и отличный от него идентификатор потоковой передачи второго вида, назначенный соответствующей потоковой передаче, и указание предусмотренного типа, который использован или соответственно используется исключительно для этого вида записей.

15. Применение DNS-сервера (6) для предоставления файла (11) идентификатора потоковой передачи, при этом файл (11) идентификатора потоковой передачи содержит записи, каждая из которых содержит идентификатор потоковой передачи первого вида, назначенный потоковой передаче, и отличный от него идентификатор потоковой передачи второго вида, назначенный соответствующей потоковой передаче, и указание предусмотренного типа, который использован или соответственно используется исключительно для этого вида записей.

16. Устройство (1, 2) организации потоковой передачи в сети TSN, которое выполнено и/или сконфигурировано

- для отправки сообщения-запроса (8) на DNS-сервер (6), на котором сохранены записи, каждая из которых содержит идентификатор потоковой передачи первого вида, назначенный потоковой передаче, и отличный от него идентификатор потоковой передачи второго вида, назначенный соответствующей потоковой передаче, и указание предусмотренного типа, который использован или соответственно используется исключительно для этого вида записей, при этом сообщение-запрос (8) содержит по меньшей мере один идентификатор потоковой передачи первого вида, который известен устройству, и предусмотренный тип,

- для получения от DNS-сервера (6) сообщения-ответа (9), которое содержит идентификатор потоковой передачи второго вида, относящийся к потоковой передаче, и

- для использования полученного идентификатора потоковой передачи второго вида для подключения к соответствующей потоковой передаче.

17. Устройство (1, 2) по п.16, отличающееся тем, что идентификатором потоковой передачи первого вида является имя потоковой передачи, используемое упомянутым устройством (1, 2) для идентификации потоковой передачи, и/или идентификатором потоковой передачи второго вида является ID потоковой передачи, используемое сетью для идентификации потоковой передачи.

18. Устройство (1, 2) по любому из пп.16 и 17, отличающееся тем, что упомянутое устройство (1, 2) выполнено и/или сконфигурировано для отправки сообщения-запроса (8) в форме DNS-запроса и/или для приема сообщения-ответа (9) в форме DNS-запроса.

19. Устройство (1, 2) по любому из пп.16-18, отличающееся тем, что упомянутое устройство (1, 2) выполнено и/или сконфигурировано для отправки на DNS-сервер (6) сообщений (13) обновления, которые содержат запись для DNS-сервера (6), которая содержит по меньшей мере один идентификатор потоковой передачи первого вида и по меньшей мере один идентификатор потоковой передачи второго вида для потоковой передачи и указание предусмотренного типа.

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

Images