Протокол PIM. Основные преимущества PON. Посмотрим, что будет происходить после настройки роутеров
Главный писатель по вопросам технологий
Вам кто-то послал по электронной почте файл PIM, и вы не знаете, как его открыть? Может быть, вы нашли файл PIM на вашем компьютере и вас заинтересовало, что это за файл? Windows может сказать вам, что вы не можете открыть его, или, в худшем случае, вы можете столкнуться с соответствующим сообщением об ошибке, связанным с файлом PIM.
До того, как вы сможете открыть файл PIM, вам необходимо выяснить, к какому виду файла относится расширения файла PIM.
Tip: Incorrect PIM file association errors can be a symptom of other underlying issues within your Windows operating system. These invalid entries can also produce associated symptoms such as slow Windows startups, computer freezes, and other PC performance issues. Therefore, it highly recommended that you scan your Windows registry for invalid file associations and other issues related to a fragmented registry.
Ответ:
Файлы PIM имеют Сжатые файлы, который преимущественно ассоциирован с Personal Information Manager File.
Файлы PIM также ассоциированы с PixMaker Project File, Ultimate Draw Pascal Text Mode Image, PIMPLE Compressed File (Ilia Muraviev) и FileViewPro.
Иные типы файлов также могут использовать расширение файла PIM. Если вам известны любые другие форматы файлов, использующие расширение файла PIM, пожалуйста, свяжитесь с нами , чтобы мы смогли соответствующим образом обновить нашу информацию.
Как открыть ваш файл PIM:
Самый быстрый и легкий способ открыть свой файл PIM - это два раза щелкнуть по нему мышью. В данном случае система Windows сама выберет необходимую программу для открытия вашего файла PIM.
В случае, если ваш файл PIM не открывается, весьма вероятно, что на вашем ПК не установлена необходимая прикладная программа для просмотра или редактирования файлов с расширениями PIM.
Если ваш ПК открывает файл PIM, но в неверной программе, вам потребуется изменить настройки ассоциации файлов в вашем реестре Windows. Другими словами, Windows ассоциирует расширения файлов PIM с неверной программой.
Установить необязательные продукты - FileViewPro (Solvusoft) | | | |
PIM Инструмент анализа файлов™
Вы не уверены, какой тип у файла PIM? Хотите получить точную информацию о файле, его создателе и как его можно открыть?
Теперь можно мгновенно получить всю необходимую информацию о файле PIM!
Революционный PIM Инструмент анализа файлов™ сканирует, анализирует и сообщает подробную информацию о файле PIM. Наш алгоритм (ожидается выдача патента) быстро проанализирует файл и через несколько секунд предоставит подробную информацию в наглядном и легко читаемом формате.†
Уже через несколько секунд вы точно узнаете тип вашего файла PIM, приложение, сопоставленное с файлом, имя создавшего файл пользователя, статус защиты файла и другую полезную информацию.
Чтобы начать бесплатный анализ файла, просто перетащите ваш файл PIM внутрь пунктирной линии ниже или нажмите «Просмотреть мой компьютер» и выберите файл. Отчет об анализе файла PIM будет показан внизу, прямо в окне браузера.
Перетащите файл PIM сюда для начала анализа
Просмотреть мой компьютер »
Пожалуйста, также проверьте мой файл на вирусы
Ваш файл анализируется... пожалуйста подождите.
Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.
И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.
Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.
Введение
Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.Первым делом озвучим несколько понятий, чтоб исключить дальнейшие недопонимания. Существует три вида трафика:
- unicast - одноадресный, один источник потока один получатель
- broadcast - широковещательный, один источник, получатели все клиенты в сети
- multicast - многоадресный, один отправитель, получатели некоторая группа клиентов
Какой вид трафика использовать для IPTV?
Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast.
Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255
.
Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.
Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).
Немного о том, как работает IGMP.
Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:Клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это запрос “JOIN 224.12.0.1 ”.
Если пользователь переключается на другой канал, то он сначала отправляет уведомление MR, что он отключает канал News или покидает эту группу. Для IGMP это “LEAVE 224.12.0.1 ”. А затем повторяет аналогичный запрос JOIN для нужного канала.
MR иногда спрашивает всех: “а какой группе кто подключен?”, чтобы отключать тех клиентов, с которыми оборвалась связь и они не успели отправить уведомление LEAVE . Для этого MR использует запрос QUERY .
Ответ абонента на этот запрос это MEMBERSHIP REPORT , который содержит список всех групп, в которых состоит клиент.
Настройка multicast routing.
Предположим, что клиенты одной группы смотрят один и тот же мультик, но находятся они в разных сегментах сети (network A и network B). Для того, чтобы они получили свой мультик и придуман multicast routing.
Пример настройки роутеров MR1 и MR2.
| Network A | 10.1.0.0/24 |
| Network B | 10.2.0.0/24 |
| Network C | 10.3.0.0/24 |
| MR1 | MR2 |
| MR1#sh run Ip multicast-routing |
MR2#sh run Ip multicast-routing |
Команда "ip multicast-routing " включает соответствующий routing, если же он выключен, то роутер не пересылает multicast пакеты, т.е. они не дойдут до недоумевающего зрителя мультиков.
Остановимся чуть поподробнее на команде "ip pim sparse-mode ".
Про режимы протокола PIM и сам протокол.
PIM (Protocol Independent Multicast) - протокол маршрутизации multicast рассылки. Он заполняет свою таблицу multicast маршрутизации на основе обычной таблицы маршрутизации. Эти таблицы можно просмотреть с помощью команд “sh ip mroute ” и “sh ip route ” соответственно. Целью протокола PIM является построение дерева маршрутов для рассылки multicast сообщений.У протокола PIM существует два основных режима: разряженный (sparse mode ) и плотный (dense mode ). Таблица multicast маршрутизации для них выглядит немного по-разному. Иногда эти режимы рассматривают как отдельные протоколы - PIM-SM и PIM-DM.
В нашей конфигурации на интерфейсах мы указали режим "ip pim sparse-mode ".
(config-if)# ip pim?
Dense-mode Enable PIM dense-mode operation
sparse-dense-mode Enable PIM sparse-dense-mode operation
sparse-mode Enable PIM sparse-mode operation
………
В чем же разница?
PIM-DM использует механизм лавинной рассылки и отсечения (flood and prune). Другими словами. Роутер MR отправляет всем все multicast потоки, которые на нем зарегистрированы. Если клиенту не нужен какой-то из этих каналов, то он от него отказывается. Если все клиенты, висящие на роутере, отказались от канала, то роутер пересылает “спасибо, не надо” вышестоящему роутеру.PIM-SM изначально не рассылает зарегистрированные на нем TV-каналы. Рассылка начнется только тогда, когда от клиента придет на нее запрос.
Т.е. в PIM-DM MR отправляет всем, а потом убирает ненужное, а в PIM-SM MR начинает вещание только по запросу.
Если члены группы разбросаны по множеству сегментов сети, что характерно для IPTV, PIM-DM будет использовать большую часть полосы пропускания. А это может привести к снижению производительности. В этом случае лучше использовать PIM-SM.
Между PIM-DM и PIM-SM существуют еще отличия.
PIM-DM строит дерево отдельно для каждого источника определенной multicast группы, т.е. multicast маршрут будет характеризоваться адресом источника и адресом группы. В multicast таблице маршрутизации будут записи вида (S,G), где S - source, G - group.
У PIM-SM есть некоторая особенность. Этому режиму необходима точка рандеву (RP - rendezvous point ) на которой будут регистрироваться источники multicast потоков и создавать маршрут от источника S (себя) до группы G: (S,G).
Таким образом, трафик идет с источника до RP по маршруту (S,G), а далее до клиентов уже по общему для источников определенной группы дереву, которое характеризуется маршрутом (*,G) - "*" символизирует «любой источник». Т.е. источники зарегистрировались на RP, и далее клиенты уже получают поток с RP и для них не имеет значения, кто был первоначальным источником. Корнем этого общего дерева будет RP.
Точкой рандеву является один из multicast роутеров, но все остальные роутеры должны знать “кто здесь точка RP”, и иметь возможность до нее достучаться.
Пример статического определения RP (MR1). Объявим всем multicast роутерам, что точкой рандеву является 10.0.0.1 (MR1):
Все остальные роутеры должны знать маршрут до RP:
ip route 10.0.0.0 255.255.255.0 10.10.10.1
Существуют так же и другие способы определения RP, это auto-RP и bootstarp router, но это уже тема для отдельной статьи (если кому-нибудь будет интересно – пожалуйста )?
Посмотрим, что будет происходить после настройки роутеров.
Мы по-прежнему рассматриваем схему с роутерами MR1 (RP) и MR2. Как только включаем линк между роутерами MR1 и MR2, то должны увидеть в логах сообщения Для MR1:
%PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3
Для MR2:
%PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0
Это говорит о том, что роутеры установили отношение соседства по протоколу PIM друг с другом. Проверить это также можно с помощью команды:
MR1#sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable
| Neighbor Address | Interface | Uptime/Expires | Ver | DR Prio/Mode |
| 10.10.10.2 | Ethernet3 | 00:03:05/00:01:37 | v2 | 1 / DR S |
Не забываем про TTL.
В качестве тестового сервера мне было удобно использовать плеер VLC. Однако, как позже обнаружилось, даже если выставить через GUI достаточный TTL, он все равно (надеюсь только в использованной мной версией) упорно отправлял multicast пакеты с TTL=1. Запускать упрямого пришлось с опцией «vlc.exe –ttl 3» т.к. у нас на пути будет два роутера, каждый из которых уменьшает TTL пакета на единицу.Как же все таки обнаружить проблему с TTL? Один из способов. Пусть сервер вещает канал 224.12.0.3 с TTL=2, тогда на роутере MR1 пакеты проходят нормально, а за роутером MR2 клиенты уже не смогут смотреть свой мультик.
Обнаруживается это с помощью команды «sh ip traffic» на MR2. Смотрим на поле “bad hop count” – это число пакетов, которые “умерли”, как им и отмеряно, по TTL=0.
MR2#sh ip traffic
IP statistics:
Rcvd: 36788 total, 433 local destination
0 format errors, 0 checksum errors, 2363 bad hop count
……………………………………
Если этот счетчик быстро увеличивается, значит - проблема в TTL.
Show ip mroute
После включения вещания трех каналов на сервере в таблице multicast маршрутизации наблюдаем следующее:MR1# sh ip mroute
(*, 224.12.0.1), 00:03:51/stopped, RP 10.0.0.1, flags: SP
(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT
Outgoing interface list: Null
(*, 224.12.0.2), 00:00:45/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.2), 00:00:45/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.12.0.3), 00:00:09/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.0.0.2, 224.12.0.3), 00:00:09/00:02:59, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null
Видим, что появились маршруты вида (S,G), например (10.0.0.2, 224.12.0.3), т.е. зарегистрировался источник 10.0.0.2, который вещает для группы 224.12.0.3. А так же маршруты с RP до клиента: (*,G), например (*, 224.12.0.3) – которые они будут использовать, так называемое общее для всех дерево.
Как только на интерфейс MR1 (RP) приходит запрос на получение канала 1, в multicast таблице маршрутизации происходят следующие изменения:
MR1#sh ip mroute
…………………
(*, 224.12.0.1), 00:33:16/00:02:54, RP 10.0.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
(10.0.0.2, 224.12.0.1), 00:33:17/00:03:25, flags: T
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53
Стало видно, что приходят запросы на эту группу с порта Ethernet3.
RPF проверка
Возможна ситуация, когда роутер получает multicast поток на двух интерфейсах. Кого из этих двух интерфейсов роутер будет считать источником?Для этого он выполняет проверку RPF (Reverse Path Forwarding) - проверяет по обычной unicast таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.
Протокол PIM-SM является одной из двух версий протокола PIM (Protocol Independent Multicast - независимое от протокола групповое вещание), описываемого в спецификации RFC 2362:
- версии плотного режима PIM-DM (Protocol Independent Multicast - Dense Mode);
- версии разряженного режима PIM-SM (Protocol Independent Multicast - Sparse Mode).
Эти версии существенно отличаются друг от друга способом построения и использования покрывающего дерева, но у них есть и одно общее свойство. Оно вынесено в название каждого из этих протоколов и означает независимость данного протокола от конкретных протоколов маршрутизации. Если DVMPR использует в своей работе механизмы RIP, а протокол MOSPF является расширением протокола OSPF, то протокол PIM может работать совместно с любым протоколом маршрутизации. Протокол PIM задействует готовые таблицы маршрутизации для продвижения групповых пакетов и служебных сообщений и для него не имеет значения, с помощью какого протокола маршрутизаторы строят эти таблицы.
Протокол PIM-DM похож на протокол DVMPR. Он, также являясь протоколом плотного режима, строит для доставки групповых пакетов деревья с вершиной в источнике, используя для этого проверки продвижения по реверсивному пути и технику широковещания и усечения. Основное отличие состоит в том, что PIM-DM применяет готовую таблицу маршрутизации, а не строит ее сам, как это делает DVMPR.
Главной особенностью протокола PIM-SM является то, что он рассчитан на работу в разряженном режиме, то есть он посылает групповые пакеты только по явному запросу получателя. Для доставки данных каждой конкретной группе получателей протокол PIM-SM строит одно разделяемое дерево, общее для всех источников этой группы (рис. 1).
Рис. 1. Разделяемое дерево протокола PIM-SM
Вершина разделяемого дерева не может располагаться в источнике, так как источников может быть несколько. В качестве вершины разделяемого дерева используется специально выделенный для этой цели маршрутизатор, выполняющий функции точки встречи (RP). Все маршрутизаторы в пределах домена PIM-SM должны обладать согласованной информацией о расположении точки встречи. Различные группы могут иметь как одну и ту же, так и разные точки встречи.
Самым распространенным и возможно самым простым способом конфигурирования локальных (в пределах одного домена PIM-SM) точек встречи является назначение их статически среди множества маршрутизаторов данного домена. Это" приводит к весьма определенной конфигурации и позволяет в дальнейшем легче находить ошибки, чем при других подходах.
Для получателей каждой конкретной группы и источников, вещающих на эту группу, маршрутизатор точки встречи является посредником, который связывает их между собой.
Процесс доставки протоколом PIM-SM группового тр&фика от источника к получателям, принадлежащим некоторой группе, может быть представлен трехэтапным:
1. Построение разделяемого дерева с вершиной в точке встречи, которое описывает пути доставки групповых пакетов между точкой встречи и членами данной группы. Это дерево называют также деревом точки встречи (Rendezvous Point Tree, RPT).
2. Построение дерева кратчайшего пути (Shortest Path Tree, SPT), которое будет доставлять пакеты между источником данной группы и точкой встречи.
3. Построение набора SPT-деревьев, которые ради повышения эффективности будут использованы для доставки пакетов непосредственно между источником и каждым из получателей группы.
ПРИМЕЧАНИЕ
Порядок следования этапов не фиксирован. Например, источники группового вещания могут начать передачу до того, как появятся слушатели, заинтересованные в этом трафике, или дерево кратчайшего пути между источником и его слушателями может уже быть построенным, когда будет сделан новый запрос на присоединение к группе.
Рассмотрим работу протокола PIM-SM на простом примере. На рис. 2 показана одно-доменная сеть, в которой протокол PIM-SM устанавливает связь между одним получателем A и одним источником 5. Будем считать, что работа сети соответствует модели ASM (групповое вещание из любого источника), на всех узлах сети развернут протокол IGMP и все маршрутизаторы поддерживают протокол PIM-SM. Будем считать также, что точка встречи сконфигурирована статически: и источники, и получатели знают индивидуальный адрес точки встречи, роль которой в этой сети играет маршрутизатор D. Для оповещения узлов сети об адресе точке встречи имеется стандартный протокол автоматического оповещения, называемый протоколом загрузки.
Рис. 2. Этап 1 - построение разделяемого дерева
Этап 1 - построение разделяемого RPT-дерева от получателя к точке встречи. Когда разделяемое дерево уже построено, трафик группового вещания передается от точки встречи в направлении заинтересованных получателей. Однако процесс построения разделяемого дерева движется в обратном направлении - от получателей к точке встречи на основе пошагового (hop-by-hop) подхода.
Итак, пусть хост A решает присоединиться к группе G, по этой причине он посылает IGMP-сообщениё отчета о членстве, содержащее адрес группы G, в локальную сеть, к которой он подключен. Это сообщение будет получено маршрутизатором С, через который данная локальная сеть подключена к другим сетям.
Маршрутизатор С, получив от хоста A это IGMP-сообщение, посылает сообщение протокола PIM-SM о присоединении (join) на индивидуальный адрес маршрутизатора Д выполняющего функции точки встречи. Это сообщение продвигается обычным образом на основе таблиц маршрутизации, построенных любыми протоколами маршрутизации. На всех промежуточных маршрутизаторах, расположенных вдоль пути от хоста-получателя к точке встречи, фиксируется состояние продвижения для данной группы. Каждый маршрутизатор добавляет интерфейс, принявший сообщение протокола PIM-SM о присоединении, к своему списку интерфейсов, через которые заинтересованным получателям может быть доставлен трафик группы, упомянутой в сообщении. В результате для данной группы формируется разделяемое дерево, и его корнем является точка встречи.
В нашем примере на данном этапе нет активных источников, поэтому данные группового вещания еще не поступают к точке встречи (см. рис. 2).
Этап 2 - построение SPT-дерева от источника к точке встречи. Когда источник S становится активным и начинает посылать пакеты с групповым адресом в свою локальную сеть, маршрутизатор F, к которому эта сеть непосредственно подключена, замечает, что источник 5 стал источником группового вещания. Маршрутизатор F посылает Р1М-сообщение о регистрации (register) на индивидуальный адрес точки встречи (маршрутизатора D). При этом сообщение о регистрации инкапсулируется в пакет группового вещания от источника 5 (рис. 3).
Когда маршрутизатор D (точка встречи) получает сообщение о регистрации, он реагирует на это двумя действиями. Во-первых, он продвигает инкапсулированные данные группового вещания по разделяемому дереву (RPT) от точки встречи до получателя, во-вторых, посылает PIM-сообщение о присоединении назад по направлению к источнику с тем, чтобы создать дерево кратчайшего пути (SPT). Это сообщение передается от одного маршрутизатора к другому, при этом информация о присоединении к группе фиксируется на соответствующих интерфейсах.
Как только дерево кратчайшего пути от источника к точке встречи построено, маршрутизатор D начинает получать по две копии каждого пакета группового вещания. Одна копия приходит от источника 5 по вновь созданному кратчайшему пути, другая - от маршрутизатора F, который, продолжая реагировать на выявленную активность источника 5, снова посылает сообщение о регистрации, в котором в инкапсулированном виде содержится вторая копия группового пакета. Когда маршрутизатор точки встречи распознает эту ситуацию, он посылает маршрутизатору F сообщение с требованием прекратить регистрацию (register stop). Получив это сообщение для данной пары источник-группа, маршрутизатор F прекращает генерировать сообщения о регистрации и инкапсулировать в них групповые пакеты источника. Вместо этого он начинает посылать их в исходном виде с групповым адресом, так как к этому моменту источник уже присоединился к дереву группы, и это присоединение зафиксировано на нужных маршрутизаторах.
Рис. 3. Этап 2 - регистрация источника с построением дерева кратчайшего пути
Таким образом, поток данных группового вещания от источника S начинает передаваться по SPT-дереву до точки встречи, а затем далее от точки встречи по разделяемому дереву ко всем заинтересованным получателям (в том числе на маршрутизатор С, к которому подключен хост A).
Этап 3 - построение дерева кратчайшего пути от источника к получателю. Когда маршрутизатор С получает первый групповой пакет, он узнает из его заголовка IP-адрес отправителя, каковым в данном случае является источник 5. На основании этого адреса маршрутизатор С пытается построить дерево кратчайшего пути непосредственно от источника до самого себя. В нашем примере кратчайший путь - это путь через маршрутизатор В. Маршрутизатор С посылает сообщение о присоединении маршрутизатору В, который затем, в свою очередь, посылает сообщение о присоединении маршрутизатору F. При этом каждый из них фиксирует интерфейс, на который он будет направлять пакеты да данной группы.
Теперь, когда дерево кратчайшего пути для пары (источник 5, получатель A) построено, маршрутизаторы F, В и С«ачинают продвигать пакеты группового вещания вдоль него. Когда пакеты начинают прибывать на маршрутизатор С, он обнаруживает по две копии каждого пакета - одна приходит по новому кратчайшему пути через маршрутизатор В, другая по разделяемому дереву от маршрутизатора D. Чтобы прекратить дублирование, маршрутизатор С посылает PIM-сообщение об отсечении точки встречи (маршрутизатору D), который отсекает источник от разделяемого RPT-дерева (рис. 4).
Рис. 4. Этап 3 - построение дерева кратчайшего пути от источника к получателю
С этого момента маршрутизатор С получает только по одной копии каждого пакета от и точника 5 через свое отдельное дерево кратчайшего пути и передает его в локальную сет в которой находится получатель.
Для упрощения мы описали случай, когда в сети имеется только одна точка встречи и с здается только одно разделяемое дерево. Однако технология допускает наличие в сет нескольких точек встречи. Решение о том, сколько в сети должно быть точек встречи и ю их расположить, составляет предмет планирования сети и протоколом PIM не опред ляется.
Протоколы PIM и IGMP
Чтобы доставить мультикаст от источника до получателя существует много протоколов - IGMP, PIM, MSDP, MBGP, MOSPF, DVMRP. В настоящее время из выше перечисленных протоколов используются в основном: PIM и IGMP .
Рисунок 6.8
PIM (Protocol Independent Multicast) строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы. PIM обеспечивает построение графа сети, связывающего все хосты в определенной группе, причем между двумя хостами существует только один путь. Такой граф называют покрывающим деревом. Протокол PIM осуществляет постоянный мониторинг покрывающего дерева, и время от времени отсекает те ветви дерева, которые из-за изменения состояния сети уже не ведут к членам той или иной группы.
Протокол IGMP (Internet Group Management Protocol ) – gротокол группового управления в Интернете, был разработан в 1989 году. IGMP- это сетевой протокол взаимодействия клиентов мультикастового трафика и ближайшего к ним маршрутизатора. С помощью этого протокола маршрутизатор узнаёт о наличии получателей мультикастового трафика и об их отключении. Роль IGMP очень проста: если клиентов нет, то передавать мультикастовый трафик в сегмент не надо. Если появился клиент, он уведомляет маршрутизатор с помощью IGMP о том, что хочет получать трафик.
Источник программ IPTV не нуждается в протоколе IGMP. Любой компьютер, подключенный к Интернету, может стать источником группового вещания, при этом ему не требуется никакого дополнительного программного обеспечения, кроме того, которое включено в состав обычной реализации стека TCP/IP.
Чтобы стать получателем групповых данных, узел должен «выразить» свою заинтересованность маршрутизатору, к которому непосредственно подсоединена его сеть. Для этого хост должен установить взаимодействие с маршрутизатором по протоколу IGMP.
При вещании ТВ программ в режиме multicast видеосервер рассылает только один видеопоток (для каждой из ТВ-программ), независимо от числа абонентов.
На участке соединения видеосервер - шлюз доступа (Ethernet-коммутатор, DSLAM) происходит трансляция всех ТВ-программ (рисунок 6.6). На участке соединения коммутатор - STB транслируется только та программа, которую выбрал абонент для просмотра. Это происходит посредством протокола IGMP.
Рисунок 6.6
В IGMP определено три типа сообщений:
1) Запрос о членстве . С помощью этого сообщения маршрутизатор пытается узнать, в каких группах состоят хосты в локальной сети, присоединенной к какому-либо его интерфейсу. Запрос о членстве существует в двух вариантах: в одном из них маршрутизатор делает общий запрос обо всех группах «IGMP General Query» (общий запрос), в другом его интересует информация только о некоторой конкретной группе, адрес которой указывается в запросе«IGMP Group Sepcific Query» .
2) Отчет о членстве (IGMP Report ) . Этим сообщением хосты отвечают маршрутизатору, который послал в сеть запрос о членстве. В сообщении содержится информация об IP-адресе группы, в которой они состоят. Маршрутизатор, являясь членом всех групп, получает сообщения, направленные на любой групповой адрес. Для маршрутизатора, получающего ответные сообщения, важен только факт наличия членов той или иной группы, а не принадлежность конкретных хостов конкретным группам. Отчет о членстве хост может послать не только в ответ на запрос маршрутизатора, но и по собственной инициативе, когда он пытается присоединиться к определенной группе. После такого сообщения хост может рассчитывать на то, что трафик для этой группы действительно будет доставляться в сеть, к которой этот хост принадлежит.
3) Покинуть группу (IGMP Leave ). Это сообщение хост может использовать, чтобы сигнализировать «своему» маршрутизатору о желании покинуть некоторую группу, в которой он до этого состоял. Получив это сообщение, маршрутизатор посылает специфический запрос о членстве членам только этой конкретной группы « IGMP Group Sepcific Query» , и если не получает на него ответ (то есть это был последний хост в группе), то перестает передавать трафик группового вещания для этой группы.
Сообщения с запросами о членстве посылаются маршрутизатором регулярно с некоторой частотой. На каждом из интерфейсов с установленными средствами IGMP маршрутизаторами поддерживаются кэш-таблицы групп. Кэш-таблица содержит список всех групп, в составе которых есть хотя бы один член. Для каждой строки таблицы установлен таймаут. Маршрутизатор регулярно посылает запросы «IGMP General Query» (по умолчанию - каждые 60 секунд), чтобы проверить, что в каждой группе еще имеются члены. Если для некоторой группы ответ не поступает в течение установленного для нее тайм-аута, то соответствующая строка удаляется из кэш-таблицы, и маршрутизатор считает, что членов этой группы в сети больше нет.
Локальная сеть может иметь несколько хостов, заинтересованных в получении трафика одной и той же группы, но маршрутизатору достаточно подтверждения только от одного хоста для того, чтобы продолжить передавать трафик в сеть для этой группы. Основываясь на информации, полученной с помощью IGMP, маршрутизаторы могут определять, в какие подключенные к ним сети необходимо передавать групповой трафик.
Чтобы хост смог получать трафик группового вещания, недостаточно установить на нем протокол IGMP, с помощью которого хост может отправить сообщение своему маршрутизатору о желании присоединиться к группе. Помимо этого, надо сконфигурировать сетевой интерфейс хоста так, чтобы он стал захватывать из локальной сети кадры, несущие в себе пакеты группового вещания для той группы, к которой присоединился хост.
Чтобы стало понятнее, как работает IPTV, рассмотрим небольшой пример (рисунок 6.9) . Для работы IPTV необходим роутер, поддерживающий multicast (далее MR ). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить, какому клиенту какой отправлять TV-канал. В сети есть сервер (Мulticast источник ), подключённый к роутеру MR. Этот сервер вещает TV-каналы, например:
Предположим, что клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это сообщение«IGMP Report 224.12.0.1 ” . После получения Multicast Router"ом данного сообщения, MR регистрирует его, и Ethernet коммутатор (SW ) приступает к копированию широковещательных пакетов, предназначенных для данной группы, в порт, к которому подключен клиент. Клиент начинает получать трафик.
Рисунок 6.9 – Принцип работы IGMP
Если клиент переключается на другой канал, то он сначала отправляет уведомление MR , что он отключает канал News, т.е. покидает эту группу. Для IGMP это сообщение “LEAVE 224.12.0.1 ” (ВЫЙТИ из группы 224.12.0.1). А затем опять шлёт сообщение «IGMP Report » для нужного канала.
Маршрутизатор MR получив сообщение “LEAVE ” для какой-либо группы, должен убедиться, что больше никаких других получателей этого канала нет, посылает сообщение «IGMP Group Specific Query» дважды. И если ни один STB не откликнется, то MR перестаёт передавать трафик этой группы.
Кроме того, MR периодически (каждые 60 секунд) опрашивает всех: «к какой группе кто подключен?», для выяснения состава групп в текущей момент времени, чтобы отключать тех клиентов, с которыми оборвалась связь. При этом MR использует запрос «IGMP General Query » (Общий з апрос) . Если на 3 подряд «Query» не было с интерфейсов MR ответа «IGMP Report» для какой-то группы, MR удаляет этот канал из своей таблицы мультикастовой маршрутизации - перестаёт посылать трафик этого канала до тех пор, пока к этой группе не подключится, хотя бы один клиент.
После присоединения к необходимой группе, клиентское оборудование начинает принимать поток данных по протоколу UDP на порт 1234.
Таким образом, переключение каналов с дистанционного пульта-«ленивчика », столь привычное и простое для пользователей традиционного телевидения, представляет сложность для сети IPTV. Всякий раз, когда пользователь IPTV переключает канал, в сети начинает кипеть работа :
1) Во-первых, пользователя следует отключить от группы Multicast.
2) Во-вторых, подключить его к новой группе Multicast.
3) В-третьих, если канал вещания вообще отсутствует в данный момент, так как его никто не смотрит, значит, нужно инициировать вещание и создать новую группу Multicast.
Итак, повторим ещё раз:
IGMP Report - посылается клиентом при подключении, если клиент хочет получать трафик конкретной группы или в ответ на запрос маршрутизатора о членствеIGMP Query.
IGMP General Query - посылается маршрутизатором периодически, чтобы проверить, какие группы сейчас нужны.
IGMP Group Sepcific Query - посылается маршрутизатором в ответ на сообщение Leave, чтобы узнать есть ли другие получатели в этой группе. В качестве адреса получателя указывается адрес мультикастовой группы.
IGMP Leave - посылается клиентом, когда тот хочет покинуть группу.
7 Пассивные оптические сети (PON) – переворот в широкополосном доступе
Оптоволокно на последней
миле: это надо PONять
Технология PON используется для реализации структур FTTH «волокно до жилища». Возможности технологии GPON удивляют в первую очередь тем, что доступ к ресурсам сети Интернет возможен на скорости до 1 Гб/с, что в двести раз выше, чем по медным линиям.
Сеть строится с помощью пассивных делителей оптической мощности (сплиттеров), не требующих питания и обслуживания. Особенностью технологии является 100% оптический канал от АТС до квартиры или офиса клиента, что позволяет повысить качество передачи сигнала (голоса, данных, видео) и в десятки раз увеличить скорость передачи данных.
Инфраструктура GPON отличается крайней неприхотливостью и безопасностью: не требует электропитания и может быть смонтирована в любом, даже неприспособленном помещении
Основные преимущества PON:
1 Простота и перспективность реализации распределительной инфраструктуры;
2 Отсутствие промежуточных активных узлов;
3 Быстрое развёртывание сети;
4 Простота сопряжения с любым внешним оборудованием;
5 Высокая гибкость при развитии и наращивании сети;
6 Независимое использование любых протоколов работы и технологий связи;
7 Повышенная надёжность;
8 Простота подключения новых абонентов и удобство обслуживания (подключение, отключение или выход из строя одного или нескольких абонентских узлов никак не сказывается на работе остальных);
9 Невысокая стоимость создания сети и т. д.
Protocol Independent Multicasts (PIM) /Мультикастинг не зависящий от протокола/ - семейство многоадресных протоколов маршрутизации для сетей, созданный для решения проблем групповой маршрутизации. PIM называется протоколо-независимым, потому что базируется на традиционных маршрутных протоколах (например Border Gateway Protocol), вместо того, чтобы создавать собственную сетевую топологию .
Режимы работы протокола
Уплотнённый режим (Dense Mode)
Protocol Independent Multicast-Dense Mode (PIM-DM) используется для компактных групп, обычно с высокой плотностью получателей. Он косвенно строит деревья кратчайшего пути, наводняя всю сеть мультикастингом, а затем на обратном пути обрезает ветви дерева, где не имеется получателей. Этим PIM-DM реализует метод RPF (Reverse Path Forwarding) с усечением (Prune). Пробные датаграммы рассылаются каждые 3 минуты, что является одним из недостатков данного протокола .
Часто протокол PIM-DM используется совместно с протоколом DVMRP (Distance Vector Multicast Routing Protocol).
Описание протокола PIM-DM находится в RFC 3973 .
Разреженный режим (Sparse Mode)
Protocol Independent Multicast-Sparse Mode (PIM-SM) строит однонаправленные общие деревья с корнем в точке рандеву (Rendezvous Point - RP) для каждой мультикастинг-группы. В качестве RP может быть использован любой маршрутизатор, который поддерживает протокол PIM. Дополнительно PIM-SM создает деревья кратчайшего пути для каждого отправителя.
PIM-SM используется для сетей с произвольным рассредоточением пользователей с ограниченной пропускной способностью сетевых каналов .
Описание протокола PIM-SM находится в RFC 4601 .
Мультикаст с заданным источником (Source Specific Multicast)
Protocol Independent Multicast-Source Specific Multicast (PIM-SSM) развивает концепцию выделения мультикаста не только групповым адресом, но и адресом источника трафика для группы. Является производным от PIM-SM
Описание протокола PIM-SSM находится в RFC 4607 .
Напишите отзыв о статье "Protocol Independent Multicast"
Примечания
Ссылки
- (англ.) (PDF)
|
||||||||||||||||||||||||||||||||||
Отрывок, характеризующий Protocol Independent Multicast
Кутузов отступил к Вене, уничтожая за собой мосты на реках Инне (в Браунау) и Трауне (в Линце). 23 го октября.русские войска переходили реку Энс. Русские обозы, артиллерия и колонны войск в середине дня тянулись через город Энс, по сю и по ту сторону моста.День был теплый, осенний и дождливый. Пространная перспектива, раскрывавшаяся с возвышения, где стояли русские батареи, защищавшие мост, то вдруг затягивалась кисейным занавесом косого дождя, то вдруг расширялась, и при свете солнца далеко и ясно становились видны предметы, точно покрытые лаком. Виднелся городок под ногами с своими белыми домами и красными крышами, собором и мостом, по обеим сторонам которого, толпясь, лилися массы русских войск. Виднелись на повороте Дуная суда, и остров, и замок с парком, окруженный водами впадения Энса в Дунай, виднелся левый скалистый и покрытый сосновым лесом берег Дуная с таинственною далью зеленых вершин и голубеющими ущельями. Виднелись башни монастыря, выдававшегося из за соснового, казавшегося нетронутым, дикого леса; далеко впереди на горе, по ту сторону Энса, виднелись разъезды неприятеля.
Между орудиями, на высоте, стояли спереди начальник ариергарда генерал с свитским офицером, рассматривая в трубу местность. Несколько позади сидел на хоботе орудия Несвицкий, посланный от главнокомандующего к ариергарду.
Казак, сопутствовавший Несвицкому, подал сумочку и фляжку, и Несвицкий угощал офицеров пирожками и настоящим доппелькюмелем. Офицеры радостно окружали его, кто на коленах, кто сидя по турецки на мокрой траве.
– Да, не дурак был этот австрийский князь, что тут замок выстроил. Славное место. Что же вы не едите, господа? – говорил Несвицкий.
– Покорно благодарю, князь, – отвечал один из офицеров, с удовольствием разговаривая с таким важным штабным чиновником. – Прекрасное место. Мы мимо самого парка проходили, двух оленей видели, и дом какой чудесный!
– Посмотрите, князь, – сказал другой, которому очень хотелось взять еще пирожок, но совестно было, и который поэтому притворялся, что он оглядывает местность, – посмотрите ка, уж забрались туда наши пехотные. Вон там, на лужку, за деревней, трое тащут что то. .Они проберут этот дворец, – сказал он с видимым одобрением.
