IPTV: вещание мультикаст трафика в VRF и глобальную таблицу
С радостью для себя обнаружил на Хабре некоторое количество статей на тему весьма мне близкую — IPTV.
Решил внести свой небольшой вклад написанием этой статьи.
Небольшое введение
Один интернет провайдер центрального региона имеет в коммерческой эксплуатации в нескольких городах услугу IPTV. Одной из основ, точнее, самой главной основой является наполнение этой услуги контентом, это очевидно. И разумеется, оператору гораздо удобнее агрегировать весь контент в одном месте, откуда, используя свои межрегиональные сети передачи данных, вещать его в филиалы.
Постановка задачи
Оператор в месте агрегации контента имеет:
1. Серверную ферму предоставления услуги IPTV;
2. Стык фермы с региональной сетью филиала;
3. Стык фермы с МСПД (межрегиональная сеть передачи данных);
4. МСПД от региональной сети на серверной ферме отделена с использованием VRF.
Необходимо на одном из серверов фермы шифровать мультикаст и передавать его в таком виде в МСПД и региональную сеть, не используя никаких дополнительных устройств видеомультиплексирования. Сервер шифрования выступает здесь в качестве стримера, на который наложены определенные ограничения:
1. Один телеканал — одна лицензия, одна мультикастовая группа.
2. Стримить сервер может только с одного интерфейса (один адрес источника мультикаста — это основная проблема).
ОС сервера шифрования — RHEL5.4, сетевое оборудование фермы — Cisco серии 7600.
Решение
Сперва необходимо схематично отобразить, что же мы хотим получить на выходе:
Логичное и элегантное решение задачи — настройка на сервере шифрования моста, включающего в себя два тегированных виртуальных интерфейса.
В VRF и глобальной таблице настраиваем два vlan, в которых организуем маршрутизацию мультикаста по протоколу PIM.
Предположим, что тег vlan в глобальной таблице — 10, а в VRF — 20, тогда:
interface Vlan10
description # Multicast to Region in GRT #
mac-address 001c.b7a4.3d10
ip address 192.168.10.1 255.255.255.240
ip pim dense-mode
load-interval 30
end
interface Vlan20
description # Multicast to MSPD #
mac-address 001c.b7a4.3d11
ip vrf forwarding MSPD
ip address 192.168.20.1 255.255.255.240
no ip redirects
ip pim dense-mode
load-interval 30
end
Следующим шагом настроим порт подключения сервера шифрования:
interface GigabitEthernet2/20
description # STREAM OUT #
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20
switchport mode trunk
load-interval 30
no mdix auto
no cdp enable
spanning-tree bpdufilter enable
end
Включение spanning-tree bpdufilter в данном случае обязательно, иначе линуксовый мост и cisco не «договорятся».
Теперь необходимо поднять сам мост. Для это требуется bridge-utils, поддержка моста ядром, поддержка сетевым интерфейсом тегированного трафика 802.1q.
В RHEL настройка интерфейсов производится с помощью конфигурационных файлов в /etc/sysconfig/network-scripts/ Их и приведу:
ifcfg-eth1.10:
DEVICE=eth1.10
VLAN=yes
HWADDR=00:21:5E:65:FA:F2
ONBOOT=yes
BOOTPROTO=static
TYPE=Ethernet
BRIDGE=stream1
ifcfg-eth1.20:
DEVICE=eth1.20
VLAN=yes
HWADDR=00:21:5E:65:FA:F2
ONBOOT=yes
BOOTPROTO=static
TYPE=Ethernet
BRIDGE=stream1
Теперь конфиг самого моста ifcfg-stream1:
DEVICE=stream1
HWADDR=00:21:5E:65:FA:F2
ONBOOT=yes
BOOTPROTO=static
TYPE=Bridge
IPADDR=192.168.10.2
NETMASK=255.255.255.240
STP=off
Перед поднятием интерфейсов, во избежание возникновения петель через мост отключаем ip forward в ядре:
echo 1 > /proc/sys/net/ipv4/ip_forward
и настраиваем iptables и ebtables дропать пакеты, проходящие через цепочки FORWARD.
Теперь смело поднимаем интерфейсы, добавляем маршруты и второй адрес на бридж: ifup eth1.10 && ifup eth1.20 && ifup stream1
ip addr add 192.168.20.2/28 dev stream1
ip route add 224.0.0.0/4 dev stream1
Вуаля, теперь наш шифрованный мультикаст полился и в глобальную таблицу, и в VRF.
Осталась одна деталь: для того, чтобы маршрутизировать мультикаст из VRF далее в сеть оператора, нужно в VRF на 7600 иметь маршрут на адрес источника, а именно на 192.168.10.2:
ip route vrf mspd 192.168.10.2 255.255.255.255 192.168.20.2
Надеюсь эта статья окажется кому-то полезной.
И спасибо НЛО за приглашение!
Сети для самых маленьких. Часть 9.1. Мультикаст. Общее понимание Multicast
Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.
В этой серии статей сосредоточимся на следующем:
Содержание серии статей про мультикаст
На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.
«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже» — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол IGMP там как-то задействован.
В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP Snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.
Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.
Уже гораздо позже я пришёл в к следующему правилу:
И теперь с высоты оттраблшученных кейсов я понимаю, что там не могло быть никаких проблем с настройкой сетевой части — глючило конечное оборудование.
Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.
Общее понимание Multicast
Как известно, существуют следующие типы трафика:
Unicast Одноадресная рассылка — один отправитель, один получатель. (пример: запрос HTTP-странички у WEB-сервера). Broadcast Широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (пример: ARP-запрос). Multicast Многоадресная рассылка — один отправитель, много получателей. (пример: IPTV). Anycast Одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (пример: Anycast DNS).
Раз уж мы решили поговорить о мультикасте, то, пожалуй, начнём этот параграф с вопроса, где и как он используется.
Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — multicast — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.
Второе применение — это, например, репликация операционной системы на множество компьютеров разом. Это подразумевает загрузку больших объёмов данных с одного сервера.
Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.
Ещё одно применение — это служебные сообщения протоколов. Например, OSPF в своём широковещательном домене рассылает свои сообщения на адреса 224.0.0.5 и 224.0.0.6. И обрабатывать их будут только те узлы, на которых запущен OSPF.
Сформулируем два основных принципа мультикастовой рассылки:
В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.
Пример 1
Начнём с самого простого случая:
На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.
При этом, заметьте, клиент и сервер не обязательно должны иметь адреса из одной подсети и пинговать друг друга — достаточно, чтобы они были в одном широковещательном домене. Мультикастовый поток просто льётся с сервера, а клиент его просто принимает. Вы можете попробовать это прямо у себя на рабочем месте, соединив патчкордом два компьютера и запустив, например, VLC.
Надо заметить, что в мультикасте нет никакой сигнализации от источника, мол, «Здрасьте, я Источник, не надо немного мультикаста?». Сервер-источник просто начинает вещать в свой интерфейс мультикастовые пакеты. В нашем примере они напрямую попадают клиенту и тот, собственно, сразу же их и принимает.
Если на этом линке отловить пакеты, то вы увидите, что мультикастовый трафик — это ни что иное, как море UDP-пакетов.
Содержимое мультикастового трафика
Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком.
Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.
Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.
В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.
Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.
Зависимость нагрузки на сеть от количества пользователей при передаче юникаст и мультикаст трафика
Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?
Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G».
То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.
Пример 2
Добавим в схему коммутатор и ещё несколько клиентов:
Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN’а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.
Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.
В данной ситуаци трафик будут получать даже те, кто этого в общем-то и не хотел, то есть на нём не запущен ни плеер, ни что бы то ни было другое. Но только, если он в том же VLAN’е. Позже мы разберёмся, как с этим бороться.
Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).
Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать. Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.
| Адрес | Значение |
|---|---|
| 224.0.0.0 | Не используется |
| 224.0.0.1 | Все узлы данного сегмента |
| 224.0.0.2 | Все мультикастовые узлы данного сегмента |
| 224.0.0.4 | Данный адрес выделялся для покойного протокола DVMRP |
| 224.0.0.5 | Все OSPF-маршрутизаторы сегмента |
| 224.0.0.6 | Все DR маршрутизаторы сегмента |
| 224.0.0.9 | Все RIPv2-маршрутизаторы сегмента |
| 224.0.0.10 | Все EIGRP-маршрутизаторы сегмента |
| 224.0.0.13 | Все PIM-маршрутизаторы сегмента |
| 224.0.0.18 | Все VRRP-маршрутизаторы сегмента |
| 224.0.0.19-21 | Все IS-IS-маршрутизаторы сегмента |
| 224.0.0.22 | Все IGMP-маршрутизаторы сегмента (v2 и v3) |
| 224.0.0.102 | Все HSRPv2/GLBP-маршрутизаторы сегмента |
| 224.0.0.107 | PTPv2 — Precision Time Protocol |
| 224.0.0.251 | mDNS |
| 224.0.0.252 | LLMNR |
| 224.0.0.253 | Teredo |
| 224.0.1.1 | NTP |
| 224.0.1.39 | Cisco Auto-RP-Announce |
| 224.0.1.40 | Cisco Auto-RP-Discovery |
| 224.0.1.41 | H.323 Gatekeeper |
| 224.0.1.129-132 | PTPv1/PTPv2 |
| 239.255.255.250 | SSDP |
Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.
Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.
Вот, собственно, самые базисные вещи касательно мультикаста.
Мы рассмотрели простую ситуацию, когда источник и получатель находятся в одном сегменте сети. Трафик, полученный коммутатором, просто рассылается им во все порты — никакой магии.
Но пока совсем непонятно, как трафик от сервера достигает клиентов, когда между ними огромная провайдерская сеть линкмиап? Да и откуда, собственно, будет известно, кто клиент? Мы же не можем вручную прописать маршруты, просто потому что не знаем, где могут оказаться клиенты. Не ответят на этот вопрос и обычные протоколы маршрутизации. Так мы приходим к пониманию, что доставка мультикаст — это нечто совершенно новое для нас.
Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.
Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.
С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы.
Использование протоколов PIM и IGMP на участках сети
Что такое mvr iptv
Региональные представители:
Глава 3: IPTV MULTICAST трансляция как услуга
В предыдущих двух статьях мы построили головную станцию (стример) и научились транслировать услугу IPTV Unicast-ом при помощи relaying. По большому счету, многим небольшим провайдерам этого достаточно, особенно если представить, что услуга IPTV носит некоммерческий, а маркетинговый характер. Однако для того, чтобы предложить своим клиентам качественный, легко управляемый, коммерческий продукт, с большим выбором пакетов телепрограмм, изложенный ранее метод не подходит. На помощь таким провайдерам приходит трансляция IPTV при помощи multicast рассылок.
Multicast
На вопрос, что же такое Multicast легко найти ответ, так, например, Википедия считает, что это специальная форма широковещания, при которой сетевой пакет одновременно направляется определённому подмножеству адресатов — не одному (unicast), и не всем (broadcast). С данной формулировкой трудно не согласиться. Технология IP Multicast очень выгодна в использовании, когда один и тот же набор данных должны получать сотни и тысячи подписчиков на эти данные, без увеличения нагрузки на сеть. Довольно трудно себе представить сервер, способный выдать хотя бы пятимегабитный поток данных тысячам потребителей. Так как обслуживание двухсторонних соединений процесс довольно ресурсоемкий, да еще и дублирование одних и тех же данных явное свидетельство нерациональной расточительности.
— сегмент сети, в котором планируется использование Multicast, должен быть построен на управляемых коммутаторах;
— управляемые коммутаторы должны поддерживать протокол IGMP, при помощи которого определяется членство в Multicast группе порта.
Подходы к реализации Multicast вещания
На сегодняшний день существует несколько технологий доставки Multicast трафика подписчикам, основные из них это:
Попробуем коротко разобраться с этими подходами. Для маршрутизации multicast трафика существует специальный протокол — PIM. В свою очередь PIM имеет два режима работы:
— PIM-DM (dense mode) или режим рассылки и отсечения;
— PIM-SM (sparse mode) или режим, при котором рассылка начинается только тогда, когда появляется запрос на членство в группе.
Разница в этих режимах работы заключается в том, что при использовании режима PIM-DM multicast роутер рассылает все зарегистрированные на нем multicast группы и только потом отсекает те, в которые никто не подписался. Напротив, режим PIM-SM рассылает multicast потоки только после того, когда на него придет IGMP запрос на членство в группе multicast рассылки. Также существует еще одно существенное отличие между режимами PIM-DM и PIM-SM, заключается оно в том, что для режима PIM-SM необходима так называемая точка рандеву — RENDEZVOUS POINT (RP). Точка рандеву — это место, где регистрируются все источники Multicast потоков. Таким образом, все Multicast потоки собираются в этой точке и из нее выдаются членам группы. В итоге, потребители Multicast потоков абсолютно ничего не знают об источнике потока.
Также существует еще один способ доставки IPTV потребителям — это MVR или, если перевести аббревиатуру, Регистрация Мультикастовых VLAN’ов. Суть данного способа заключается в том, что multicast трафик бежит по сети в отдельном VLAN, а вот уже MVR подмешивает этот трафик в порты, запросивших определенную Multicast группу клиентов.
Поскольку в рамки статьи не входит рассмотрение каждого из описанных выше подходов, то остановимся только на одном из них.
Реализация трансляции с использованием PIM-SM.
Для данной реализации использовался коммутатор BD-COM S3928GX, который вполне сгодиться для ядра довольно таки не маленькой сети, так как это полноценный L3 свитч на борту которого можно установить 4*10G порта XFP, а при условии, что цена очень гуманна, альтернатив сегодня не так уж и много.
На рисунке представлена примерная схема реализации:
Настройка коммутатора сводиться к следующим шагам:
1. Создадим VLAN 111 и включим в него наш стример порт 23.
2. Включим потребителя IPTV в уже существующий дефолтный VLAN 1 порт 21
3. Определим в каком режиме будет работать маршрутизация Multicast
4. Включим в VLAN 1 поддержку IGMP
5. На VLAN 111 настроим поддержку PIM
Собственно, на этом настройка коммутатора заканчивается, а ниже я приведу полный конфиг свитча.
Теперь пришло время проверить, а все ли работает так, как нам хотелось. Потребителем IPTV будет выступать компьютер с установленным Linux и программой VLC Player (www.videolan.org). Для удобства просмотра я подготовил маленький плэйлист с двумя ранее настроенными каналами:
Загрузив плэйлись в плэйер, на экране появился «Первый» канал. Теперь осталось убедиться в том, что мы все правильно настроили и в наш порт прилетает единственная multicast группа. Для это запустим tcpdump и посмотрим, а что же твориться на нашем сетевом интерфейсе.
Теперь переключим канал и опять глянем в tcpdump
Как видим, при переключении телеканала IGMP отключается от одной группы и подключается к другой.
Базовая настройка MVR на коммутаторе для IPTV
На практике мультикаст трафик может передаваться в одном VLAN вместе с пользовательским трафиком, или в отдельном VLAN, называемом также Multicast VLAN. Последний подход получил название Multicast VLAN Registration или MVR.
Рассмотрим настройку коммутатора доступа для работы с multicast в представленной топологии на примере ISCOM 2600:
Multicast VLAN – номер VLAN, в котором приходит на коммутатор multicast трафик.
Router port – порт коммутатора, к которому подключен multicast маршрутизатор.
Для настройки MVR в режиме глобальной конфигурации создадим два сегмента VLAN: клиентский VLAN 10 и multicast VLAN 100. Назначим VLAN 100 в качестве multicast VLAN для любого доступного клиентам канала. Укажем router VLAN, т.е. VLAN, в который приходит multicast и активируем MVR. Запретим прохождение неизвестного multicast трафика во всех VLAN.
Raisecom(config)# create vlan 10,100 active
Raisecom(config)# igmp mvr mcast-vlan 100 group any
Raisecom(config)# igmp mrouter vlan 100 gigaethernet 1/1/28
Raisecom(config)# igmp mvr
Raisecom(config)# mac-address multicast drop-unknown vlan 1-4094
Настроим uplink порт, на который приходит multicast трафик, так называемый router port. Т.к. multicast вместе с другими сервисами приходит из вышестоящей сети, обычно router port настраивается в режиме trunk. В нашем случае на uplink порт GE1/1/28 multicast приходит во VLAN 100, а прочий клиентский трафик во VLAN 10.. Активируем MVR.
Raisecom(config)# interface gigaethernet 1/1/28
Raisecom(config-gigaethernet1/1/28)# switchport trunk allowed vlan 10,100
Raisecom(config-gigaethernet1/1/28)# switchport mode trunk
Raisecom(config-gigaethernet1/1/28)# igmp mvr
После этого настроим клиентские порты. К этим портам подключено клиентское оборудование для обработки multicast трафика, будь то set-top box, компьютер или другой коммутатор. Клиентские порты настроим в режиме access во VLAN 10. Разрешим на них прохождение multicast трафика из VLAN 100 и активируем MVR.
Raisecom(config)# interface range gigaethernet 1/1/1-2
Raisecom(config-range)# switchport access vlan 10
Raisecom(config-range)# switchport access egress-allowed vlan 100 confirm
Raisecom(config-range)# igmp mvr
Raisecom#show igmp mvr
igmp mvr running :Enable
igmp mvr port :GE1/1/1 GE1/1/2 GE1/1/28
igmp mvr multicast vlan(ref) :100(all)
igmp aging time(s) :260
Для просмотра IPTV необходимо осуществить подключение каналу (подписаться на multicast рассылку). Рассмотрим пример подключения с помощью IPTV плеера. Для этого выберем опцию подключиться по URL и укажем адрес нашего канала 239.1.1.1.
После это IPTV плеер отправляет пакет IGMP join, а на коммутаторе создается запись MVR member.
Текущие просматриваемые multicast рассылки можно посмотреть с помощью команды:
Raisecom#show igmp mvr member
R-Ring port D-Dynamic S-Static
Port User-vlan Group Mcast-vlan Live-time(s) Flag
GE1/1/1 10 239.1.1.1 100 250 D
Когда абонент больше не нуждается в получении multicast трафика, например завершает воспроизведение в IPTV плеере, на коммутатор отправляется сообщение IGMP leave group, и запись MVR member на коммутаторе удаляется.
Raisecom#show igmp mvr member
R-Ring port D-Dynamic S-Static
Port User-vlan Group Mcast-vlan Live-time(s) Flag
На этом базовая настройка завершена. В статье была рассмотрена базовая конфигурация MVR на коммутаторе доступа для передачи multicast трафика. Подход MVR получил широкое распространение при организации сервисов IPTV, а также видеонаблюдения.
