Из Википедии, бесплатной энциклопедии
  (Перенаправлено с IP Multicast )
Перейти к навигации Перейти к поиску

Многоадресная IP-рассылка - это метод отправки дейтаграмм Интернет-протокола (IP) группе заинтересованных получателей за одну передачу. Это специфическая для IP форма многоадресной рассылки, которая используется для потоковой передачи мультимедиа и других сетевых приложений. Он использует специально зарезервированные блоки многоадресных адресов в IPv4 и IPv6 .

Протоколы, связанные с многоадресной IP-рассылкой, включают протокол управления группами Интернета , независимую от протокола многоадресную рассылку и регистрацию многоадресной VLAN . Отслеживание IGMP используется для управления многоадресным IP-трафиком в сетях уровня 2 .

Многоадресная IP-рассылка описана в RFC  1112 . Многоадресная IP-рассылка была впервые стандартизирована в 1986 году. [1] Ее спецификации были расширены в RFC 4604, чтобы включить управление группами, и в RFC 5771, чтобы включить адреса с административной областью действия. 

Техническое описание [ править ]

Обзор [ править ]

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

Наиболее распространенным протоколом транспортного уровня для использования многоадресной адресации является протокол дейтаграмм пользователя (UDP). По своей природе UDP не является надежным - сообщения могут быть потеряны или доставлены не по порядку. Надежные протоколы многоадресной рассылки , такие как Pragmatic General Multicast (PGM), были разработаны для добавления обнаружения потерь и повторной передачи поверх многоадресной IP-рассылки.

Ключевые концепции многоадресной IP-рассылки включают групповой IP-адрес многоадресной рассылки, [2] дерево многоадресной рассылки и создание дерева, управляемого получателем. [3]

Групповой IP-адрес многоадресной рассылки используется источниками и получателями для отправки и получения многоадресных сообщений. Источники используют групповой адрес в качестве IP-адреса назначения в своих пакетах данных. Получатели используют этот групповой адрес, чтобы сообщить сети, что они заинтересованы в получении пакетов, отправленных этой группе. Например, если некоторый контент связан с группой 239.1.1.1 , источник будет отправлять пакеты данных, предназначенные для 239.1.1.1 . Получатели этого контента будут информировать сеть о том, что они заинтересованы в получении пакетов данных, отправленных группе 239.1.1.1 . Приемник включается 239.1.1.1 . Протокол, обычно используемый получателями для присоединения к группе, называется Internet Group Management Protocol. (IGMP). [4]

С протоколами маршрутизации, основанными на общих деревьях, после того, как получатели присоединяются к определенной группе многоадресной IP-рассылки, для этой группы строится дерево рассылки многоадресной рассылки. Наиболее широко для этого используется протокол независимой от протокола многоадресной передачи (PIM). Он устанавливает деревья многоадресной рассылки таким образом, чтобы пакеты данных от отправителей в группу многоадресной рассылки доходили до всех получателей, которые присоединились к группе. Существуют разновидности реализаций PIM: разреженный режим (SM), плотный режим (DM), многоадресная передача для конкретного источника (SSM) и двунаправленный режим (Bidir или разреженный режим SDM). Из них PIM-SM наиболее широко используется по состоянию на 2006 год ; [ необходима цитата ]SSM и Bidir - более простые и масштабируемые варианты, разработанные недавно и набирающие популярность. [ необходима цитата ]

Для операции многоадресной IP-рассылки не требуется, чтобы активный источник знал о получателях группы. Построение многоадресного дерева управляется получателем и инициируется сетевыми узлами, которые находятся рядом с получателями. Многоадресная IP-рассылка масштабируется для большого количества получателей. Модель многоадресной IP-рассылки была описана архитектором Интернета Дэйвом Кларком следующим образом: «Вы помещаете пакеты на один конец, а сеть сговаривается, чтобы доставить их любому, кто попросит». [5]

Многоадресная IP-рассылка создает информацию о состоянии для каждого дерева многоадресной рассылки в сети. Если маршрутизатор является частью 1000 деревьев многоадресной рассылки, он имеет 1000 записей многоадресной маршрутизации и пересылки. С другой стороны, маршрутизатору многоадресной рассылки не нужно знать, как достичь всех других деревьев многоадресной рассылки в Интернете. Ему нужно знать только о деревьях многоадресной рассылки, для которых у него есть нисходящие приемники. Это ключ к масштабированию сервисов с многоадресной адресацией. Напротив, одноадресный маршрутизатор должен знать, как достичь всех других одноадресных адресов в Интернете, даже если он делает это, используя только маршрут по умолчанию. По этой причине агрегация является ключом к масштабированию одноадресной маршрутизации. Кроме того, существуют базовые маршрутизаторы, которые передают маршруты в сотни тысяч, потому что они содержат таблицу маршрутизации Интернета.

Маршрутизация [ править ]

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

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

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

В локальной сети многоадресная доставка контролируется IGMP (в сети IPv4 ) и MLD (в сети IPv6 ); внутри домена маршрутизации используются PIM или MOSPF ; между доменами маршрутизации используются протоколы междоменной многоадресной маршрутизации, такие как MBGP .

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

  • Протокол управления группами Интернета (IGMP)
  • Независимая от протокола многоадресная передача (PIM)
  • Протокол дистанционной векторной многоадресной маршрутизации (DVMRP)
  • Многоадресная рассылка, сначала открытый кратчайший путь (MOSPF)
  • Многоадресный BGP (MBGP)
  • Протокол обнаружения источника многоадресной рассылки (MSDP)
  • Обнаружение многоадресного прослушивателя (MLD)
  • Протокол многоадресной регистрации GARP (GMRP)

Доставка уровня 2 [ править ]

Одноадресные пакеты доставляются определенному получателю в подсети Ethernet или IEEE 802.3 путем установки определенного MAC-адреса уровня 2 в адресе пакета Ethernet. Широковещательные пакеты используют широковещательный MAC-адрес (FF: FF: FF: FF: FF: FF).

Многоадресные пакеты IPv4 доставляются с использованием диапазона MAC-адресов Ethernet 01: 00: 5e: 00: 00: 00–01: 00: 5e: 7f: ff: ff (с OUI, принадлежащим IANA ). Этот диапазон имеет 23 бита доступного адресного пространства. Первый октет (01) включает бит широковещательной / многоадресной передачи. Младшие 23 бита 28-битного IP-адреса многоадресной рассылки отображаются в 23 бита доступного адресного пространства Ethernet. Это означает, что доставка пакетов неоднозначна. Если два хоста в одной подсети подписываются на разные группы многоадресной рассылки, адрес которых отличается только в первых 5 битах, пакеты Ethernet для обеих групп многоадресной рассылки будут доставлены на оба узла, что потребует от сетевого программного обеспечения на узлах отбрасывания ненужных пакетов. [6]

Для многоадресных IPv6- адресов MAC-адрес Ethernet определяется четырьмя младшими октетами, объединенными ИЛИ с MAC-адресом 33: 33: 00: 00: 00: 00, так, например, IPv6-адрес FF02: DEAD: BEEF :: 1: 3 будет отображаться на MAC-адрес Ethernet 33: 33: 00: 01: 00: 03. [7]

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

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

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

Рекомендации по беспроводной связи [ править ]

Беспроводная сеть 802.11 использует тот же диапазон MAC-адресов, что и проводной Ethernet, для сопоставления IP-адресов многоадресной передачи. Однако беспроводная сеть 802.11 обрабатывает многоадресный трафик по-разному, в зависимости от конфигурации сообщения индикации трафика доставки (DTIM) и настроек интервала маяка . Если ни одна из станций в базовом наборе услуг не находится в режиме энергосбережения, многоадресные пакеты отправляются сразу после их прибытия. Если одна или несколько станций находятся в режиме энергосбережения, точки доступа затем доставляют многоадресный трафик только после каждого интервала DTIM и передают с одной из поддерживаемых скоростей в наборе базовой скорости. В большинстве беспроводных точек доступа, по умолчанию конфигурации для этого интервала либо 102,4 мс [ править] (Интервал маяка = 100 мс, DTIM = 1) или 204,8 мс [ требуется ссылка ] (интервал маяка = 100 мс, DTIM = 2), а скорость передачи составляет либо 1 Мбит / с, либо 6 Мбит / с [ требуется ссылка ] , в зависимости от рабочий диапазон и режим защиты. Параметры DTIM и интервала маяка можно настроить для повышения производительности многоадресной передачи в беспроводных сетях. [8]

В отличие от Ethernet, большая часть трафика в 802.11 надежно отправляется с использованием ACK и NACK, так что радиопомехи не вызывают невыносимо больших потерь пакетов. Однако многоадресные пакеты отправляются один раз и не подтверждаются, поэтому они подвержены гораздо более высокому уровню потерь. Существуют различные методы решения этой проблемы, такие как выбор многократной одноадресной рассылки данных многоадресной рассылки каждому клиенту или запрос ACK от каждого клиента. [9] Некоторые методы требуют только модификации точки доступа и поддерживаются в некоторых устройствах корпоративного класса, в то время как другие улучшения потребуют модификации клиентов, и поэтому не получили широкого распространения.

Безопасная многоадресная рассылка [ править ]

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

Использование IPsec в качестве канала связи требует установления соединения точка-точка. Обычно безопасность требуется от отправителя к получателю, что подразумевает, что отправитель должен реплицировать пакет по каждому из защищенных соединений - по одному для каждого получателя. По мере роста числа получателей отправитель должен масштабироваться, реплицируя пакет каждому из получателей. Нагрузка на обработку, возлагаемую на отправителя, может быть высокой, что ограничивает масштабируемость отправителя. Для безопасной передачи многоадресной рассылки потребовался новый метод, получивший название Secure Multicast или Multicast Security.

Инженерная группа Интернета ( IETF) создал новый Интернет-протокол (IP) для безопасной передачи многоадресного трафика по пакетной сети. Определение протокола было разработано в Рабочей группе безопасности многоадресной рассылки и привело к нескольким запросам комментариев (RFC), которые теперь используются в качестве стандартов для защиты многоадресного IP-трафика. Протокол позволял отправителю зашифровать многоадресный пакет и переслать его в пакетную сеть на оптимальном дереве распределения. Пакет может быть воспроизведен в оптимальных местах сети и доставлен всем получателям. Получатели могут дешифровать пакет и пересылать его в защищенной сетевой среде. Отправитель многоадресного пакета не знает потенциальных получателей; поэтому создание парных ключей шифрования (по одному для каждого получателя) невозможно.Отправитель должен зашифровать пакеты с помощью общего ключа, который все законные получатели используют для дешифрования пакетов. Безопасность системы основана на способности контролировать распространение ключей только законным получателям. Для этого IETF создалПротокол Group Domain of Interpretation (GDOI), определенный в RFC-6407. Протокол позволяет отправителю и получателю присоединиться к серверу ключей, где политики и ключи зашифрованы и распространяются среди членов группы безопасной многоадресной рассылки. Сервер ключей может аутентифицировать и авторизовать отправителей и получателей в определенной группе, где общий ключ используется для шифрования и дешифрования трафика между членами группы.

Надежная многоадресная рассылка [ править ]

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

Одна из таких схем, предложенная Cisco, - это PGM (первоначально Pretty Good Multicast, но измененная по причинам товарного знака на Pragmatic General Multicast ), [ ссылка необходима ], задокументированная в RFC 3208. В этой схеме многоадресные пакеты имеют порядковые номера, а когда пакет - пропущенный получатель может запросить повторную многоадресную рассылку пакета с другими членами группы многоадресной рассылки, игнорируя замещающие данные, если в этом нет необходимости. В расширенной версии PGM-CC была предпринята попытка сделать многоадресную IP-рассылку более «дружественной к TCP», снизив для всей группы полосу пропускания, доступную худшему приемнику.

Две другие схемы, задокументированные Инженерной группой Интернета (IETF): протокол отслеживания стандартов NACK-Oriented Reliable Multicast (NORM), задокументированный в RFC 5740 и RFC 5401, и протокол доставки файлов через однонаправленный транспорт (FLUTE), задокументированный. в RFC 6726. В дополнение к частным реализациям для них существуют реализации с открытым исходным кодом. Существуют и другие такие протоколы, такие как Scalable Reliable Multicast., и определены в различных источниках. Такие протоколы различаются по средствам обнаружения ошибок, механизмам, используемым для восстановления после ошибок, масштабируемости такого восстановления и лежащим в основе идеям, связанным с тем, что значит быть надежным. Список надежных протоколов многоадресной рассылки от ACM SIGCOMM Multicast Workshop, 27 августа 1996 г., документирует ряд подходов к проблеме.

Независимые группы, такие как Internet Protocol Multicast Standards Initiative (IPMSI), заявили, что отсутствие действительно масштабируемого протокола Secure Reliable IP Multicast, такого как предлагаемый Secure Multicast для расширенного повтора телевидения (SMART) , препятствует внедрению IP Multicast в междоменном режиме. маршрутизация. Отсутствие широко распространенной системы, которая имеет уровень безопасности AES и масштабируемую надежность, не позволяет средствам массовой информации транслировать спортивные события (например, Суперкубок) и / или последние новости о событиях в общедоступном Интернете. [ необходима цитата ]

Надежные протоколы многоадресной IP-рассылки, такие как PGM и SMART, являются экспериментальными; единственный протокол отслеживания стандартов - это NORM (версия RFC 3941 с отслеживанием стандартов указана в RFC 5401, версия RFC 3940 с отслеживанием стандартов указана в RFC 5740).

Протоколы на основе многоадресной рассылки [ править ]

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

Во многих приложениях транспортный протокол реального времени (RTP) используется для кадрирования мультимедийного контента по многоадресной передаче ; Протокол резервирования ресурсов (RSVP) может использоваться для резервирования полосы пропускания в сети , поддерживающей многоадресного распределения. Многоадресный DNS (mDNS) может использоваться для разрешения имен домена или хоста без выделенного DNS-сервера с помощью многоадресной рассылки.

Развертывание [ править ]

Многоадресная IP-рассылка широко используется на предприятиях, коммерческих биржах и в сетях доставки мультимедийного контента. Обычно многоадресная IP-рассылка используется на предприятии для приложений IPTV, таких как прямое телевещание и телевизионные собрания компаний. [ необходима цитата ]

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

Операторы платного телевидения и некоторые учебные заведения со значительным количеством студентов на территории кампуса развернули многоадресную IP-рассылку для доставки односторонних потоковых мультимедиа, таких как высокоскоростное видео, большим группам получателей. Кроме того, в некоторых случаях использовались аудио- и видеоконференции с использованием технологий многоадресной передачи. Они гораздо менее распространены и чаще всего относятся к исследовательским и образовательным учреждениям, которые часто обладают большей сетевой емкостью для удовлетворения потребностей. [ необходима цитата ] Некоторые технические конференции и собрания передаются с использованием многоадресной IP-рассылки. До недавнего времени [ когда? ] многие сессии на собраниях IETF проводились с использованием многоадресной рассылки. [цитата необходима ]

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

Многоадресная IP-рассылка также была внедрена в финансовом секторе для таких приложений, как биржевые тикеры и системы « крик-н-крик» . [10]

Хотя многоадресная IP-рассылка добилась определенного успеха в каждой из этих областей, услуги многоадресной рассылки обычно недоступны для среднего конечного пользователя. [ необходима цитата ] Есть два основных связанных фактора отсутствия повсеместного развертывания. Во-первых, пересылка многоадресного трафика накладывает большую сложность протокола на поставщиков сетевых услуг. [ необходима цитата ] Во-вторых, базовая сетевая инфраструктура предоставляет гораздо более широкую поверхность для атак, особенно уязвимую для атак типа «отказ в обслуживании». [ необходима цитата ]

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

RFC 3170 ( IP Multicast Applications: Challenges & Solutions ) содержит обзор проблем развертывания.

История [ править ]

Развитие [ править ]

Многоадресная IP-рассылка была впервые разработана Стивом Дирингом в Стэнфордском университете, за что он получил премию IEEE Internet Award. [11]

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

CastGate [ править ]

CastGate - это попытка исследовательской группы ETRO-TELE из Брюссельского университета внедрить многоадресную IP-рассылку в Интернете. [12]

Хотя многоадресная рассылка позволила бы пользователю Интернета получать мультимедийные материалы и другой контент, не создавая большой нагрузки на сеть, для большинства пользователей Интернета она по-прежнему была недоступна. Проект CastGate попытался исправить это, разрешив конечным пользователям подключаться через автоматически настроенный IP-туннель по сетям, которые изначально не поддерживали многоадресную IP-рассылку. Идея заключалась в том, что, если больше пользователей будет иметь возможность многоадресной рассылки, большее количество поставщиков контента увидят преимущество потоковой передачи контента по сравнению с многоадресной рассылкой. Была надежда, что если достаточное количество контент-провайдеров и пользователей воспользуется этой услугой, то большее количество интернет-провайдеров смогут включить многоадресную IP-рассылку для своих клиентов. [12]

CastGate предоставил программный клиент для Microsoft Windows и Linux для подключения к туннельной сети CastGate. Он также предоставил инструменты для добавления туннельных серверов и инструменты для приема сообщений протокола Session Announcement Protocol из многоадресной сети с видео- и аудиопотоками. [13]

Веб-сайт проекта поддерживался до 2007 года. [13]

Коммерческое развертывание [ править ]

Начиная с 2005 годом [14] BBC начал поощрять Великобританию на основе Интернет - провайдер принять групповую адресацию услуг в своих сетях, предоставляя BBC Radio на более высоком качестве [15] , чем доступно через их однонаправленные -addressed услуг. Это также поддерживалось различными коммерческими радиосетями, включая BBC , GCap Media , EMAP и Virgin Radio . [16]

Немецкие общественные вещатели ARD [17] и ZDF и франко-германская сеть Arte предлагают свою телепрограмму с многоадресной передачей в нескольких сетях. Австрийский провайдер Интернет-услуг Telekom Austria предлагает своим клиентам цифровой абонентской линии (DSL) телевизионную приставку, которая использует многоадресную адресацию при приеме теле- и радиопередач. В Германии аналогичную услугу предлагает T-Home, торговая марка Deutsche Telekom .

Программное обеспечение многоадресной IP-рассылки [ править ]

  • Репозиторий средств массовой информации , Великобритания : UCL, заархивировано из оригинала 2008-01-08- набор инструментов для MBone .
  • VideoLAN - это бесплатное программное обеспечение многоадресной передачи потокового видео приложения .
  • Xorp- бесплатный программный маршрутизатор с поддержкой многоадресной рассылки (IGMP, PIM).
  • Smcroute - простой инструмент для управления маршрутами многоадресной рассылки в ядре Linux.
  • SSM-ping , NO : Venås, архивировано из оригинала 26ноября2007 г. - инструмент для проверки возможности многоадресного подключения.
  • Wilbert, IGMP v3 , Kloosterhof, архивировано из оригинала 26 августа 2007 г. - хост-реализация IGMPv3 на FreeBSD.
  • IP multi (программное обеспечение), Пало-Альто: Xerox[ постоянная мертвая ссылка ]
  • Java Reliable Multicast Service , заархивировано из оригинала 30 января 2013 г. , получено 8 сентября 2012 г. - библиотеки и сервисы для создания приложений с поддержкой многоадресной рассылки
  • Реализация PIM , USC, заархивировано из оригинала 24декабря2007 г. - реализация протокола PIM, ныне устаревшего
  • qpimd - демон PIM для Quagga , GNU- Модуль PIM для Quagga Routing Suite .
  • GateD , Next hop, заархивировано из оригинала 09.09.2007 - Unix-реализация протоколов маршрутизации, включая многоадресную рассылку.
  • Код PIM-DM для GateD , Университет Орегона, заархивирован из оригинала 15октября 2007 г..
  • НОРМА , NRL - Nack-Oriented Reliable Multicast от Лаборатории военно-морских исследований США с реализацией C ++ с открытым исходным кодом.
  • ecmh (Easy Cast du Multi Hub) , Unfix - Демон многоадресной рассылки IPv6, позволяет использовать многоадресную рассылку IPv6 без необходимости использования PIM.
  • MRD6 - демон многоадресной маршрутизации IPv6
  • UFTP - зашифрованный FTP на основе UDP с многоадресной рассылкой
  • GStreamer - бесплатный программный мультимедийный фреймворк , поддерживающий многоадресную потоковую передачу видео.
  • Mcproxy (многоадресный прокси)- прокси- сервер IGMP / MLD , поддерживающий расширения многоадресной рассылки PMIPv6

См. Также [ править ]

  • Деревья на основе ядер , предложение для масштабируемости многоадресной IP-рассылки

Ссылки [ править ]

  1. ^ RFC 988
  2. ^ RFC 5771
  3. ^ RFC 1112
  4. ^ "Какой у меня IP, ваш адрес IPv4 IPv6 Decimal на myip" . Мой IP есть .
  5. ^ 1968-, Тейлор, Ян Дж. (2009). От P2P и сетей до услуг в Интернете: развивающиеся распределенные сообщества . Харрисон, Эндрю Б., Тейлор, Ян Дж., 1968- (2-е изд.). Лондон: Спрингер. ISBN 9781848001220. OCLC  314174970 .CS1 maint: числовые имена: список авторов ( ссылка )
  6. ^ RFC 1112, раздел 6.4
  7. ^ RFC 2464
  8. ^ "802.11 Multicasting" . Беспроводные сети . Проверено 8 октября 2008 .
  9. ^ "Журнал EURASIP по беспроводной связи и сети" . Журнал EURASIP по беспроводным коммуникациям и сетям .
  10. ^ Speakerbus, провайдер IP hoot-n-holler.
  11. ^ Получатели Интернет-премии (PDF) , IEEE, заархивировано из оригинала (PDF) 16 сентября 2012 г. , извлечено 26 августа 2010 г. .
  12. ^ a b Марникс Гуссен; . Питер Лифооге; Арноут Суиннен (30 сентября 2006 г.). «Проект CastGate:« Включение многоадресной передачи через Интернет для распространения контента » » (PDF) . Архивировано из оригинального (PDF) 26 мая 2011 года . Проверено 25 мая 2013 года . Презентация на конференции NORDUNET
  13. ^ a b «CastGate: Включение многоадресной передачи в Интернете» . Архивировано из оригинального 28 сентября 2007 года . Проверено 25 мая 2013 года .
  14. ^ "Союз регби", Новости , Великобритания : BBC.
  15. ^ Услуги многоадресной передачи , Великобритания: BBC.
  16. ^ "Radio", Multicast , UK: BBC Research & Development , получено 19 апреля 2012 г.
  17. ^ IPTV , DE : ARD , получено 17 мая 2015 г..

Внешние ссылки [ править ]

  • Multicast over TCP / IP (Howto), Проект документации GNU / Linux, март 1998 г.. Описывает многоадресную рассылку в ядре Linux, хотя некоторые разделы (особенно многоадресные программы) устарели и не охватывают недавнее программное обеспечение.
  • Надежная Multicast транспорта (RMT) (рабочая группа), IETF, архивируются с оригинала на 2007-12-03.
  • Multicast & Anycast Group Membership (magma) (рабочая группа), IETF, заархивировано из оригинала 14декабря2007 г..
  • Protocol Independent Multicast (pim) (рабочая группа), IETF, заархивировано из оригинала от 02.12.2007..
  • Source-Specific Multicast (ssm) (рабочая группа), IETF, заархивировано из оригинала 27 января 2007 г..
  • Multicast Security (msec) (рабочая группа), IETF, заархивировано из оригинала 16декабря2007 г..
  • Multicast , сокеты. Детали IP.
  • Многоадресная передача IP-Ethernet (учебник), CX: Firewall.
  • IP Multicast (видео), Cisco.
  • "Обзор надежных методов многоадресной рассылки", ACM SIGCOMM Multicast Workshop , Массачусетский университет, 27 августа 1996 г..
  • Флойд, Надежная многоадресная структура для облегченных сеансов и формирования фреймов на уровне приложений , ICIR. Статья, определяющая масштабируемую надежную многоадресную передачу.
  • Анализ методов многоадресной рассылки , Wikidot , получено 03 мая 2019 г..
  • Ноормохаммадпур, Мохаммад; Raghavendra, Cauligi S .; Рао, Шрирам; Kandula, Srikanth (2017), DCCast: эффективная передача данных из одной точки в другую , ассоциация USENIX, arXiv : 1707.02096 , Bibcode : 2017arXiv170702096N , получено 03 мая 2019 г..
  • Обзор архитектуры многоадресной маршрутизации в Интернете . Январь 2008 г. doi : 10.17487 / RFC5110 . RFC 5110 .