Многоадресная рассылка IP: принципы и применение

Введение

Отправка датаграмм нескольким получателям

IP-мультикаст – это метод отправки интернет-протокольных (IP) датаграмм группе заинтересованных получателей в рамках одной передачи. Это IP-специфическая форма мультикаста, используемая для потоковой передачи мультимедиа и других сетевых приложений. Он использует специально зарезервированные блоки многоадресных IP-адресов в IPv4 и IPv6. Протоколы, связанные с IP-мультикастом, включают протокол управления группами в интернете (IGMP), протокол независимого мультикаста (PIM) и регистрацию мультикаста в VLAN. IGMP snooping используется для управления IP-мультикаст трафиком в сетях второго уровня. IP-мультикаст был впервые стандартизирован в 1986 году. Его спецификации были дополнены в 2001 году для включения управления группами и в 2008 году для включения административно-ограниченных адресов.

Техническое описание

IP-мультикаст – это технология для организации связи один-ко-многим и многие-ко-многим в режиме реального времени через IP-инфраструктуру сети. Она масштабируется для большого числа получателей, не требуя предварительного знания идентификаторов получателей или их количества. Мультикаст эффективно использует сетевую инфраструктуру, поскольку источник должен отправить пакет только один раз, даже если он предназначен для большого числа получателей. Узлы сети (как правило, сетевые коммутаторы и маршрутизаторы) обеспечивают репликацию пакета для доставки его множеству получателей, при этом сообщения передаются по каждой линии связи сети только один раз. Наиболее распространенным протоколом транспортного уровня для использования мультикаст-адресации является протокол пользовательских данных (UDP). По своей природе UDP не гарантирует надежность – сообщения могут быть потеряны или доставлены не по порядку. Для обеспечения надежности мультикаст-связи, например, для обнаружения потерь и повторной передачи данных, были разработаны протоколы, такие как Pragmatic General Multicast (PGM), работающие поверх IP-мультикаста. Ключевыми понятиями IP-мультикаста являются IP-адрес группы мультикаста, дерево распространения мультикаста и создание дерева, инициируемое получателями. IP-адрес группы мультикаста используется источниками и получателями для отправки и получения мультикаст-сообщений. Источники используют групповой адрес в качестве IP-адреса назначения в своих пакетах данных. Получатели используют этот групповой адрес, чтобы сообщить сети о своем интересе к получению пакетов, отправленных в эту группу. Например, если контент связан с группой , источник будет отправлять пакеты данных, предназначенные для получателей этого контента, которые, в свою очередь, сообщат сети о своем желании получать данные, отправленные в эту группу. Получатель присоединяется к группе. Протокол, обычно используемый получателями для присоединения к группе, называется протоколом управления группами в Интернете (IGMP). При использовании протоколов маршрутизации, основанных на общих деревьях, после присоединения получателей к определенной IP-группе мультикаста для этой группы строится дерево распространения мультикаста. Наиболее широко используемым протоколом для этого является Protocol Independent Multicast (PIM). Он настраивает деревья распространения мультикаста таким образом, чтобы пакеты данных от отправителей в группу мультикаста достигали всех получателей, присоединившихся к группе. Существуют различные реализации PIM: Sparse Mode (SM), Dense Mode (DM), source-specific multicast (SSM) и Bidirectional Mode (Bidir, или Sparse Dense Mode, SDM). На сегодняшний день (2006 год) наиболее широко используется PIM SM; SSM и Bidir – более простые и масштабируемые варианты, разработанные позднее и набирающие популярность. Для работы IP-мультикаста активному источнику не требуется знать о получателях группы. Построение мультикаст-дерева инициируется получателями и начинается узлами сети, расположенными вблизи получателей. IP-мультикаст масштабируется для большого числа получателей. Архитектор Интернета Дэйв Кларк описал модель IP-мультикаста следующим образом: «Вы помещаете пакеты в один конец, и сеть стремится доставить их всем, кто об этом попросит». IP-мультикаст создает информацию о состоянии для каждого дерева распространения мультикаста в сети. Если маршрутизатор является частью 1000 деревьев мультикаста, он хранит 1000 записей маршрутизации и пересылки мультикаста. С другой стороны, мультикаст-маршрутизатору не нужно знать, как достичь всех остальных деревьев мультикаста в Интернете. Ему достаточно знать только о деревьях мультикаста, для которых у него есть нисходящие получатели. Это является ключевым фактором масштабируемости мультикаст-сервисов. В отличие от этого, маршрутизатор unicast должен знать, как достичь всех остальных unicast-адресов в Интернете, даже если он использует для этого только маршрут по умолчанию. Поэтому агрегация является ключевым фактором масштабируемости unicast-маршрутизации. Кроме того, существуют магистральные маршрутизаторы, которые содержат сотни тысяч маршрутов, поскольку они содержат таблицу маршрутизации Интернета.

IP multicast is a technique for one to many and many to many real time communication over an IP infrastructure in a network. It scales to a larger receiver population by requiring neither prior knowledge of a receiver's identity nor prior knowledge of the number of receivers. Multicast uses network infrastructure efficiently by requiring the source to send a packet only once, even if it needs to be delivered to a large number of receivers. The nodes in the network (typically network switches and routers) take care of replicating the packet to reach multiple receivers such that messages are sent over each link of the network only once. The most common transport layer protocol to use multicast addressing is User Datagram Protocol (UDP). By its nature, UDP is not reliable—messages may be lost or delivered out of order. Reliable multicast protocols such as Pragmatic General Multicast (PGM) have been developed to add loss detection and retransmission on top of IP multicast. Key concepts in IP multicast include an IP multicast group address, a multicast distribution tree and receiver driven tree creation. An IP multicast group address is used by sources and the receivers to send and receive multicast messages. Sources use the group address as the IP destination address in their data packets. Receivers use this group address to inform the network that they are interested in receiving packets sent to that group. For example, if some content is associated with group , the source will send data packets destined to Receivers for that content will inform the network that they are interested in receiving data packets sent to the group The receiver joins The protocol typically used by receivers to join a group is called the Internet Group Management Protocol (IGMP). With routing protocols based on shared trees, once the receivers join a particular IP multicast group, a multicast distribution tree is constructed for that group. The protocol most widely used for this is Protocol Independent Multicast (PIM). It sets up multicast distribution trees such that data packets from senders to a multicast group reach all receivers which have joined the group. There are variations of PIM implementations: Sparse Mode (SM), Dense Mode (DM), source specific multicast (SSM) and Bidirectional Mode (Bidir, or Sparse Dense Mode, SDM). Of these, PIM SM is the most widely deployed as of 2006; SSM and Bidir are simpler and scalable variations developed more recently and are gaining in popularity. IP multicast operation does not require an active source to know about the receivers of the group. The multicast tree construction is receiver driven and is initiated by network nodes which are close to the receivers. IP multicast scales to a large receiver population. The IP multicast model has been described by Internet architect Dave Clark as, "You put packets in at one end, and the network conspires to deliver them to anyone who asks." IP multicast creates state information per multicast distribution tree in the network. If a router is part of 1000 multicast trees, it has 1000 multicast routing and forwarding entries. On the other hand, a multicast router does not need to know how to reach all other multicast trees in the Internet. It only needs to know about multicast trees for which it has downstream receivers. This is key to scaling multicast addressed services. In contrast, a unicast router needs to know how to reach all other unicast addresses in the Internet, even if it does this using just a default route. For this reason, aggregation is key to scaling unicast routing. Also, there are core routers that carry routes in the hundreds of thousands because they contain the Internet routing table.

Доставка второго уровня

Пакеты Unicast доставляются конкретному получателю в подсети Ethernet или IEEE 802.3 путем установки конкретного MAC-адреса 2-го уровня в адрес пакета Ethernet. Пакеты широковещания используют широковещательный MAC-адрес. Пакеты IPv4 многоадресной рассылки доставляются с использованием диапазона MAC-адресов Ethernet (с OUI, принадлежащим IANA). Этот диапазон содержит 23 бита доступного адресного пространства. Первый октет (01) включает в себя бит широковещания/многоадресной рассылки. Нижние 23 бита 28-битного IP-адреса многоадресной рассылки отображаются в 23 бита доступного адресного пространства Ethernet. Это приводит к неоднозначности при доставке пакетов. Если два хоста в одной подсети подписаны на разные группы многоадресной рассылки, адреса которых отличаются только в первых 5 битах, пакеты Ethernet для обеих групп многоадресной рассылки будут доставлены обоим хостам, что потребует от сетевого программного обеспечения хостов отбрасывать ненужные пакеты. Для IPv6 многоадресных адресов MAC-адрес Ethernet формируется путем объединения (OR) четырех младших октетов с MAC-адресом, поэтому, например, IPv6-адрес будет сопоставлен с MAC-адресом Ethernet. Если коммутатор не поддерживает многоадресную рассылку, он будет пересылать этот трафик всем членам локальной сети; в этом случае сетевая карта системы (или операционная система) должна фильтровать пакеты, отправленные в группы многоадресной рассылки, на которые они не подписаны. Существуют коммутаторы, которые прослушивают трафик IGMP и поддерживают таблицу состояний, в которой указаны сетевые системы, подписанные на данную группу многоадресной рассылки. Эта таблица затем используется для пересылки трафика, предназначенного для данной группы, только ограниченному набору хостов (портов). Этот процесс прослушивания трафика IGMP называется IGMP snooping. Кроме того, некоторые коммутаторы с функциональностью 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 и маяка можно настроить для повышения производительности многоадресной рассылки в беспроводных сетях. В отличие от Ethernet, большая часть трафика в 802.11 передается надежно с использованием подтверждений (ACK) и отрицательных подтверждений (NACK), чтобы радиопомехи не вызывали чрезмерно высоких потерь пакетов. Однако пакеты многоадресной рассылки отправляются один раз и не подтверждаются, поэтому они подвержены гораздо более высоким потерям. Существуют различные способы решения этой проблемы, например, выбор повторной одноадресной рассылки многоадресных данных каждому клиенту или запрос подтверждений от каждого клиента. Некоторые методы требуют только модификации на стороне точки доступа и поддерживаются в некоторых устройствах корпоративного класса, в то время как другие улучшения потребуют модификаций клиентов и, следовательно, не получили широкого распространения.

Безопасный мультикаст

IP-мультикаст — это метод интернет-коммуникации, при котором один пакет данных может быть передан от отправителя и реплицирован для набора получателей. Методы репликации в некоторой степени зависят от среды передачи данных. Передача мультикаста по среде с присущей широковещательной природой, такой как Ethernet или спутниковая линия связи, автоматически позволяет всем получателям, непосредственно подключенным к среде, принимать пакет данных. В отличие от этого, передача мультикаста по средам типа «точка-точка» или «точка-многоточка» требует репликации пакета для каждого соединения. Процесс репликации должен выполняться оптимально, с построением дерева распространения в сети. Пакет может реплицироваться в каждой ветви дерева, что снижает необходимость для отправителя реплицировать пакет отдельно для каждого получателя. Использование IPsec в качестве канала связи требует установления соединения типа «точка-точка». Как правило, требуется обеспечение безопасности от отправителя к получателю, что подразумевает репликацию пакета отправителем для каждого защищенного соединения, по одному для каждого получателя. С ростом числа получателей отправителю необходимо масштабироваться, реплицируя пакет для каждого из них. Это может создавать высокую нагрузку на процессор отправителя, что ограничивает его масштабируемость. Для безопасной передачи мультикаста потребовался новый метод, получивший название Secure Multicast или Multicast Security. Internet Engineering Task Force (IETF) разработала новый протокол IP для безопасной передачи мультикастного трафика по пакетной сети. Определение протокола было разработано в рабочей группе Multicast Security и привело к созданию нескольких документов Request for Comments (RFC), которые теперь используются в качестве стандартов для защиты IP-мультикастного трафика. Протокол позволяет отправителю шифровать пакет мультикаста и пересылать его в пакетную сеть по оптимальному дереву распространения. Пакет может реплицироваться в оптимальных точках сети и доставляться всем получателям. Получатели способны расшифровать пакет и пересылать его в защищенной сетевой среде. Отправитель мультикастного пакета не знает потенциальных получателей, поэтому создание парных ключей шифрования (по одному для каждого получателя) невозможно. Отправитель должен шифровать пакеты, используя общий ключ, который все легитимные получатели используют для расшифровки. Безопасность системы основана на возможности контролировать распространение ключей только среди легитимных получателей. Для этого IETF разработал протокол Group Domain of Interpretation (GDOI), определенный в RFC 6407. Протокол позволяет отправителю и получателю присоединиться к серверу ключей, где политики и ключи шифруются и распространяются среди членов защищенной группы мультикаста. Сервер ключей может аутентифицировать и авторизовать отправителей и получателей в определенную группу, где общий ключ используется для шифрования и дешифрования трафика между членами группы.

IP multicast is an internet communication method where a single data packet can be transmitted from a sender and replicated to a set of receivers. The replication techniques are somewhat dependent upon the media used to transmit the data. Transmission of multicast on an inherent broadcast media such as Ethernet or a satellite link automatically allows the data packet to be received by all the receivers directly attached to the media. In contrast, transmission of multicast on media that is point to point or point to multipoint requires the packet to be replicated for each link. The replication process should occur in an optimal manner where a distribution tree is built within the network. The packet can be replicated at each of the branches in the tree. This mitigates the requirement for the sender to replicate the packet once for each recipient. The use of IPsec as a communication link requires a point to point connection establishment. Usually, the security is required from sender to receiver which implies the sender must replicate the packet on each of the secure connections one for each receiver. As the number of receivers grows, the sender must scale by replicating the packet to each of the receivers. The processing load placed on the sender can be high which limits the scalability of the sender. A new method was required to securely transmit multicast and this was referred to as Secure Multicast or Multicast Security. The Internet Engineering Task Force (IETF) created a new Internet Protocol (IP) to securely transmit multicast traffic across a packet network. The protocol definition was developed in the Multicast Security Workgroup and led to several Request for Comments (RFC) that are now used as standards for securing IP multicast traffic. The protocol allowed a sender to encrypt the multicast packet and forward it into the packet network on the optimal distribution tree. The packet may be replicated at the optimal locations in the network and delivered to all the receivers. The receivers are capable of decrypting the packet and forwarding the packet in the secure network environment. The sender of a multicast packet does not know the potential receivers; therefore, the creation of pair wise encryption keys (one for each receiver) is impossible. The sender must encrypt packets using a shared key that all the legitimate receivers use to decrypt the packets. The security of the system is based on the ability to control the distribution of the keys only to those legitimate receivers. For this, the IETF created the Group Domain of Interpretation (GDOI) protocol defined in RFC 6407. The protocol allows the sender and receiver to join a key server where policies and keys are encrypted and distributed to the members of the secure multicast group. The key server can authenticate and authorize senders and receivers into a specific group where the shared key is used to encrypt and decrypt traffic between members of the group.

Надежная мультикаст

Мультикаст, по своей природе, не является механизмом, ориентированным на установление соединения, поэтому такие протоколы, как TCP, обеспечивающие повторную передачу потерянных пакетов, не подходят. Для приложений, таких как потоковое аудио и видео, случайная потеря пакета не критична. Однако для распространения важных данных требуется механизм запроса повторной передачи. Один из таких механизмов, предложенный компанией Cisco, – PGM (первоначально Pretty Good Multicasting, но измененный на Pragmatic General Multicast из-за товарных знаков), описанный в RFC 3208. В этом механизме мультимедийные пакеты имеют порядковые номера, и при потере пакета получатель может запросить его повторную рассылку другим участникам группы мультивещания, игнорируя заменяющие данные, если они не требуются. Расширенная версия, PGM CC, стремится сделать IP-мультикаст более "дружественным к TCP", снижая пропускную способность всей группы до уровня, доступного для наихудшего получателя. Другие два механизма, описанные в Internet Engineering Task Force (IETF), – это протокол NACK Oriented Reliable Multicast (NORM), описанный в RFC 5740 и RFC 5401, и протокол File Delivery over Unidirectional Transport (FLUTE), описанный в RFC 6726. Существуют как открытые, так и проприетарные реализации этих протоколов. Существуют и другие протоколы, такие как Scalable Reliable Multicast, определенные различными источниками. Эти протоколы различаются по методам обнаружения ошибок, механизмам восстановления ошибок, масштабируемости восстановления и базовым принципам надежности. Список надежных протоколов мультивещания из семинара ACM SIGCOMM Multicast, прошедшего 27 августа 1996 года, документирует ряд подходов к решению этой проблемы. Независимые группы, такие как Internet Protocol Multicast Standards Initiative (IPMSI), утверждают, что отсутствие действительно масштабируемого и безопасного протокола надежного IP-мультикаста, такого как предложенный Secure Multicast for Advanced Repeating of Television (SMART), препятствует внедрению IP-мультикаста в междоменной маршрутизации. Отсутствие широко распространенной системы с безопасностью уровня AES и масштабируемой надежностью не позволяет транслировать в открытом Интернете массовые мероприятия, такие как спортивные соревнования (например, Супер Боул) и/или срочные новости. Надежные протоколы IP-мультикаста, такие как PGM и SMART, являются экспериментальными; единственным протоколом, соответствующим стандартам, является NORM (ревизия стандартов RFC 3941 указана в RFC 5401, а ревизия стандартов RFC 3940 – в RFC 5740).

Multicast, by its very nature, is not a connection oriented mechanism, so protocols such as TCP, which allows for retransmission of missing packets, are not appropriate. For applications such as streaming audio and video, the occasional dropped packet is not a problem. But for distribution of critical data, a mechanism is required for requesting retransmission. One such scheme, proposed by Cisco, is PGM (originally Pretty Good Multicasting, but changed for trademark reasons to Pragmatic General Multicast), documented in RFC 3208. In this scheme, multicast packets have sequence numbers and when a packet is missed a recipient can request that the packet be re multicast with other members of the Multicast group ignoring the replacement data if not needed. An expanded version, PGM CC, has attempted to make IP Multicasting more "TCP friendly" by stepping the entire group down to the bandwidth available by the worst receiver. Two other schemes documented by the Internet Engineering Task Force (IETF) are: the standards track protocol NACK Oriented Reliable Multicast (NORM), documented in RFC 5740 and RFC 5401, and the protocol File Delivery over Unidirectional Transport (FLUTE), documented in RFC 6726. Open source, in addition to proprietary, implementations exist for these. Other such protocols exist, such as Scalable Reliable Multicast, and are defined by a variety of sources. Such protocols vary in the means of error detection, the mechanisms used in error recovery, the scalability of such recovery and the underlying ideas involved in what it means to be reliable. A list of reliable multicast protocols from the ACM SIGCOMM Multicast Workshop, August 27, 1996, documents a number of approaches to the problem. Independent groups like the Internet Protocol Multicast Standards Initiative (IPMSI) have claimed that the lack of a truly scalable Secure Reliable IP Multicast protocol like the proposed Secure Multicast for Advanced Repeating of Television (SMART) have hampered the adoption of IP Multicast in inter domain routing. The lack of a widely adopted system that has AES level security and scalable reliability have kept mass media transmissions of sporting events (like the Super Bowl) and/or breaking news events from being transmitted on the Public Internet. Reliable IP Multicasting protocols, such as PGM and SMART, are experimental; the only standards track protocol is NORM (the standards track revision of RFC 3941 is specified in RFC 5401, the standards track revision of RFC 3940 is specified in RFC 5740).

Протоколы на основе мультикаста

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

Развертывание

IP-мультикаст широко используется на предприятиях, коммерческих фондовых биржах и в сетях доставки мультимедийного контента. Распространенным применением IP-мультикаста на предприятиях являются приложения IPTV, такие как трансляция прямой трансляции телевидения и телевизионные корпоративные совещания. В сфере гостеприимства IP-мультикаст стал обычным способом распространения IPTV в отелях, а в розничной торговле он широко используется для телевизионного вещания и видеорекламы. Операторы платного телевидения и некоторые учебные заведения с большим количеством общежитий развернули IP-мультикаст для доставки одностороннего потокового мультимедиа, например, высокоскоростного видео, большому количеству приемников. Кроме того, существуют примеры использования аудио- и видеоконференций на основе технологий мультикаста. Они встречаются реже и чаще всего применяются в научно-исследовательских и образовательных учреждениях, которые обычно обладают большей пропускной способностью сети для удовлетворения потребностей. Некоторые технические конференции и совещания транслируются с использованием IP-мультикаста. До недавнего времени многие сессии на встречах IETF проводились с использованием мультикаста. Другое применение мультикаста в корпоративных и университетских сетях – это распространение файлов, особенно доставка образов операционных систем и обновлений на удаленные хосты. Ключевым преимуществом загрузочных образов мультикаста перед загрузочными образами уникаста является значительно меньшее использование полосы пропускания сети. IP-мультикаст также нашел применение в финансовом секторе для таких приложений, как биржевые ленты и системы мгновенного оповещения. Высокие требования к состоянию маршрутизаторов делают невозможным работу приложений, использующих большое количество деревьев, при использовании IP-мультикаста. В качестве примера можно привести информацию о присутствии, когда каждому пользователю необходимо поддерживать как минимум одно дерево своих подписчиков, а то и несколько. Пока не разработан механизм, позволяющий масштабировать модель IP-мультикаста до миллионов отправителей и миллионов групп мультикаста, и, следовательно, пока невозможно создать полностью работоспособные универсальные приложения мультикаста. RFC 3170 (IP Multicast Applications: Challenges & Solutions) содержит обзор проблем развертывания.

IP multicast is widely deployed in enterprises, commercial stock exchanges, and multimedia content delivery networks. A common enterprise use of IP multicast is for IPTV applications such as live television distribution and televised company meetings. In the hospitality industry IP multicast has become common for IPTV distribution in hotels, and in the retail sector IP multicast is now widely used for TV distribution and video advertising applications. Pay TV operators and some educational institutions with significant on campus student housing have deployed IP multicast to deliver one way streaming media such as high speed video to large groups of receivers. Additionally, there have been some uses of audio and video conferencing using multicast technologies. These are far less prevalent and are most often relegated to research and education institutions, which often have a greater degree of network capacity to handle the demands. Some technical conferences and meetings are transmitted using IP multicast. Until recently many of the sessions at the IETF meetings were delivered using multicast. Another use of multicast within campus and commercial networks is for file distribution, particularly to deliver operating system images and updates to remote hosts. The key advantage of multicast boot images over unicasting boot images is significantly lower network bandwidth usage. IP multicast has also seen deployment within the financial sector for applications such as stock tickers and hoot n holler systems. The large state requirements in routers make applications using a large number of trees unable to work while using IP multicast. Take presence information as an example where each person needs to keep at least one tree of its subscribers, if not several. No mechanism has yet been demonstrated that would allow the IP multicast model to scale to millions of senders and millions of multicast groups and, thus, it is not yet possible to make fully general multicast applications practical. RFC 3170 (IP Multicast Applications: Challenges & Solutions) provides an overview of deployment issues.

Разработка

IP-мультитрансляция была впервые разработана Стивом Дирингом во время работы в Стэнфордском университете, за что он получил премию IEEE Internet Award. MBONE представлял собой длительный экспериментальный подход к организации мультитрансляции между узлами посредством туннелей. Хотя MBONE больше не работает, наблюдается возрождение интереса к туннелированию мультикастного трафика с целью предоставления этой услуги широкому кругу пользователей.

КастГейт

CastGate была попыткой исследовательской группы ETRO TELE при Университете свободных исследований Брюсселя (Vrije Universiteit Brussel) внедрить IP-мультикаст в Интернет. Хотя мультикаст позволил бы пользователям Интернета получать мультимедийный контент и другие данные, не создавая высокой нагрузки на сеть, он оставался недоступным для большинства пользователей. Проект CastGate стремился решить эту проблему, предоставляя конечным пользователям возможность подключения через автоматически настроенный IP-туннель в сетях, не поддерживающих IP-мультикаст изначально. Предполагалось, что расширение числа пользователей с поддержкой мультикаста побудит больше поставщиков контента использовать потоковую передачу контента по мультикасту. Была надежда, что при достаточном количестве пользователей и поставщиков контента, использующих эту услугу, больше интернет-провайдеров начнут предоставлять IP-мультикаст своим клиентам нативно.

Коммерческое использование

Начиная с 2005 года, BBC стала стимулировать интернет-провайдеров в Великобритании к внедрению многоадресных (multicast) сервисов в своих сетях, предлагая BBC Radio в более высоком качестве, чем при использовании одноадресных (unicast) сервисов. Эту инициативу поддержали и различные коммерческие радиосети, включая BBC, GCap Media, EMAP и Virgin Radio. Немецкие общественные вещатели ARD и ZDF, а также франко-германская сеть Arte, предлагают свои телевизионные программы в многоадресном режиме через несколько сетей. Австрийский интернет-провайдер Telekom Austria предоставляет своим абонентам цифровой абонентской линии (DSL) ТВ-приставку, использующую многоадресную рассылку для приема телевизионных и радиопередач. В Германии аналогичную услугу предлагает T Home, бренд Deutsche Telekom.