Групповое вещание в IP-сетях

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

Чтобы интерфейс смог принять групповую датаграмму, его надо предварительно настроить на прием и обработку групповых датаграмм. Так как IGMP не работает с транспортным уровнем, таким как TCP или UDP, значение поля IP протокола задается равным 2 (в соответствии с зарезервированным IANA значением в RFC 1700) для идентификации процесса (IGMP), прибегающего к услугам IP. Таким образом, перед приемом любых групповых пакетов, программному обеспечению верхнего уровня следует удостовериться, что интерфейсы IP- и МАС-уровней настроены на прием групповых датаграмм. Узел может быть членом не только одной группы; более того, не существует верхнего предела для количества групп (за исключением верхнего предела группового IP-адреса). Сетевые карты обладают весьма ограниченными возможностями по приему групповых пакетов. Другими словами, устанавливая версию IP для групповых взаимодействий, пользователь должен также быть в состоянии настроить сетевую карту на прием групповых пакетов. Каждая группа узлов будет иметь уникальный групповой адрес, и следовательно, он также будет отображен на групповой МАС-адрес. Не исключено, что сетевая карта сумеет поддерживать лишь ограниченное количество групповых адресов. В этом случае необходимо посоветоваться с производителем.

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

 

2. Заголовок IGMP.

 

Как  и любая другая часть уровня IP, протокол IGMP использует для передачи данных дейтаграммы протокола IP (рис. 2.1.). Сообщения протокола IGMP обозначаются в поле идентификатора протокола дейтаграммы IP значением 2.

                                            Дейтаграмма IP

Заголовок IP

Сообщение IGMP

                                    20 байт                                        8 байт

 

Рисунок 2.1.

 

Маршрутизатор, использующий протокол IGMP, посылает запросы в свои подсети, и узлы, которые принадлежат группе, обозначенной в запросе, отвечают на него. Формат заголовков IGMP для версий 1 и 2 показан на рисунке 2.2. Поле типа (Туре) может содержать одно из следующих значений:

11h- запрос о членстве;

16h - отчет о членстве версии 2;

17h - выход из состава группы;

12h - отчет о членстве версии 1.

IGMP версии 2 имеет отличный от первой версии заголовок. Поля типа и версии (Version) в заголовке версии 1 совмещены в одном поле, называемом полем типа. Чтобы групповому маршрутизатору было легче выявить различие между двумя версиями, для версии 2 было создано новое поле типа - отчетное сообщение о членстве (Membership Report Message). Маршрутизаторы

 

           0               3         7                              15                                             31

Версия	Тип	Не используется	Контрольная сумма
Групповой адрес

                Версия 1

 

             0                          7                              15                                             31

Тип	Максимальное время ожидания	Контрольная сумма
Групповой адрес

                Версия 2

Рисунок 2.2.

 

IGMP версий 1 и 2 могут сосуществовать. Маршрутизатор с установленным на нем протоколом IGMP версии 2 должен быть способен функционировать, как маршрутизатор с IGMP версии 1. Для обеспечения этого поле максимального времени ожидания ответа (Max Response Time) задается равным 0 во всех запросах (оно отображается на неиспользуемое в версии 1 поле).

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

Разницу между ними можно установить по групповому адресу в заголовке IGMP. В случае общего запроса в поле группового адреса (Group Address) будут одни нули, а в точном запросе присутствует данный групповой адрес. Оба сообщения отсылаются с помощью адреса 224.0.0.1 в IP-заголовке и отображаются на МАС-адрес 01-00-5Е-00-00-01 (используя метод преобразования, описанный ранее).

Сообщение о выходе из состава группы (LeaveGroup) является нововведением в IGMP версии 2. Оно позволяет маршрутизатору мгновенно выяснить, остались ли еще члены в группе его интерфейса, получившего сообщение LeaveGroup.

 

3. Функции маршрутизации в IGMP.

 

Групповые маршрутизаторы с помощью IGMP определяют, члены каких групп подключены к каждому из интерфейсов маршрутизатора. Эта информация, в свою очередь, служит при построении деревьев групповой адресации в процессе перенаправления групповых данных. Для информации о членстве в каждой группе имеется таймер. Маршрутизатор, на котором работает IGMP, тоже является членом любой непустой группы узлов на одном или нескольких своих интерфейсах. Групповой маршрутизатор постоянно следит за информацией о членстве для всех своих интерфейсов, а не за отдельными узлами, принадлежащими к этим группам. На самом деле следить за узлами нет необходимости. Все просто: если хотя бы один узел интерфейса маршрутизатора желает присоединиться к группе, маршрутизатор должен направлять групповые датаграммы в этот интерфейс. Неважно, сколько узлов находится на интерфейсе - 100 или 1; маршрутизатор также должен быть членом данной группы и направлять групповые датаграммы в тот же интерфейс. Групповой маршрутизатор будет узнавать, остались ли члены группы в интерфейсе, посылая туда пакет запроса.

В IGMP версии 2 маршрутизатор исполняет одну из следующих двух ролей: запрашивающего (querier) или пассивного объекта (nonquerier). Все групповые маршрутизаторы при инициализации принимают на себя функции запрашивающего маршрутизатора. Так как групповые маршрутизаторы периодически отсылают запрос на определение узлов в группах, новый маршрутизатор, в конце концов, получит запрос о том, предоставляет ли какой-либо еще маршрутизатор эту функцию. Если маршрутизатор получает еще одно сообщение запроса от другого маршрутизатора, который имеет меньший IP-адрес, то новый маршрутизатор начинает выступать в роли пассивного объекта. Если же у нового маршрутизатора будет меньший IP-адрес, то он примет на себя обязанности запрашивающего маршрутизатора, а другой маршрутизатор станет пассивным объектом.

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

На узле, имеющем более одного интерфейса, каждый интерфейс поддерживает свой собственный таймер. По истечении времени узел отвечает отчетом о членстве (Membership Report) версии 2. Поле TTL в заголовке IP будет содержать 1. Это гарантирует, что пакет не окажется перенаправлен за пределы локальной сети, в которую он передается. Узел, получивший отчет от другого узла той же группы, остановит свой таймер и не отошлет отчет. Это позволяет сохранить пропускную способность и время обработки и избежать дублирования отчетов в сети. Все осуществляется при помощи групповой адресации. 224.0.0.2 - групповой адрес всех маршрутизаторов, а 224.0.0.1 - групповой адрес всех узлов.

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

 

 

4. Присоединение узла к группе

 

Когда узел присоединяется к адресуемой группе, он немедленно передает два или три раза отчет о членстве версии 2 (т.к. IGMP не использует ICMP или TCP). Так происходит в случае, если данный узел является первым членом группы, и этот процесс повторяется при потере или повреждении первого отчета.

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

В основном, протокол IGMPv2 содержит возможность сохранения пропускной способности канала и предоставляет узлу выбор - принимать или не принимать поток данных от отдельных источников (IP-адресов) адресуемой группы, а также позволяет указать, от каких источников узел не желает принимать информацию. В любой группе может быть множество источников, В IGMP версий 1 и 2 узел обязан принимать всю информацию группы, членом которой он является, независимо от того, какой источник передает ее. Кроме того, расширены возможности сообщения о выходе из группы, так что узел в состоянии указать, от каких источников он больше не будет принимать информацию. Групповой маршрутизатор получит сообщение и, возможно, прекратит отправку информации в эту группу от данного источника.

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

 

 

 

3. Маршрутизация Multicast.

Одним из необходимых требований для передачи трафика Multicast через маршрутизируемые сети является наличие маршрутного протокола Multicast. В настоящее время известны 3 таких протокола – DVMRP, MOSPF и PIM. Назначение каждого из них заключается в нахождении внутри сети маршрута для следования группового трафика и обеспечение доставки этого трафика каждому заинтересованному участнику сети. Но перед тем как перейти к рассмотрению этих протоколов, ознакомимся с алгоритмами которые ими используются.

 

2. Алгоритмы перенаправления данных.

 

Фактически существует три алгоритма перенаправления данных, которые могут быть применены при групповой IP-адресации:

• лавинообразная рассылка (Flooding);
• остовое дерево (Spanning Tree):
• простое остовое дерево (Simple Spanning Tree);
• широковещательная рассылка по обратному пути (Reverse Path Broadcasting пути);
• групповая рассылка по обратному пути (Reverse Path Multicasting), получила наиболее широкое распространение;
• центрированное дерево (Core-Based Tree, сокращенно СВТ) - при использовании в разреженных средах (не обладающих плотной популяцией узлов) СВТ представляет собой разновидность алгоритма связующего дерева, но достаточно сильно отличается от него, чтобы попасть в отдельную категорию.

Цель всех алгоритмов - построить дерево групповой адресации для перенаправления групповых датаграмм. Некоторые алгоритмы (СВТ и иногда PIM-SM) создают только одно дерево, которое совместно используют все члены группы, даже если это дерево не предоставляет самого эффективного маршрута (кратчайшего пути) между всеми членами группы. Другие алгоритмы формируют деревья кратчайших путей, что делает возможным применение кратчайшего пути для всех членов группы (DVMRP, OSPF). Эти деревья строятся динамически, когда от источника приходит первая групповая датаграмма (за исключением MOSPF).

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

 

1. Лавинообразная рассылка

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