Протокол IGMP

2.1. Рассылка групповых сообщений в сети Internet

Рассылка групповых сообщений IP (IP-мультикастинг) предоставляет приложениям два

сервиса:

1. Доставка к нескольким пунктам назначения. Существует множество приложений, которые доставляют информацию нескольким адресатам, например, диалоговые конференции, распространение почты или новостей. Если групповая адресация не используется, эти типы сервисов вынуждены использовать TCP (при этом осуществляется доставка отдельной копии на каждый пункт назначения). Даже при существовании групповой формы сообщений, некоторые приложения все-таки используют TCP из-за его надежности.

2. Запрос от клиента к серверу. Например, бездисковая рабочая станция старается определить положение сервера загрузки. В настоящее время это осуществляется с использованием широковещательных запросов (как в случае с ВООТР), однако решение с использованием групповых запросов может уменьшить загруженность хостов, которые не предоставляют этот сервис.

ЭВМ может участвовать в мультикастинг-процессе на одном из следующих уровней:

• 0 - ЭВМ не может ни посылать, ни принимать данные

• 1 - ЭВМ может только посылать пакеты в процессе IP-мултикастинга

• 2 - ЭВМ в режиме мультикастинга может передавать и принимать пакеты

2.2. Групповые адреса

На рисунке 53 показан формат IP-адреса класса D.

Рисунок 53. Формат IP-адреса класса D.

 

В отличие от трех других классов IP адресов (А,В, С) 28 бит, отведенных под групповой идентификатор, не подвергаются дальнейшему делению. Групповой адрес (multicast group address) состоит из четырех старших бит, установленных в 1110, и идентификатора группы. В десятичном виде групповые адреса находятся в диапазоне от 224.0.0.0 до 239.255.255.255.

Некоторое количество хостов, просматривающих определенный групповой IP адрес, называется группой хостов (host group). Группа хостов может объединять хосты в разных сетях. Членство в группе динамическое: хост может вступать в группу и выходить из группы по собственному желанию. Не существует ограничений на количество хостов в группе, и хост не должен принадлежать к группе, чтобы послать сообщение в эту группу.

Некоторые адреса групп назначаются как заранее известные адреса от IANA (Internet Assigned Numbers Authority) (таблица 3.1). В этом случае группа считается постоянной группой хостов (permanent host group). Заранее известные групповые адреса приведены в последних RFC назначенных номеров (Assigned Numbers RFC). Обратите внимание на то, что постоянным в данном случае является групповой адрес, а не членство в группе.

Таблица 3.1 - Зарегистрированные мултикаст-адреса IANA Мультикастинг адрес Описание 224 0 0 0 Зарезервировано 224.0.0.1 Все системы данной субсети 224.0.0.2 Все маршрутизаторы данной субсети 224.0.0.4 Все DVMRP-маршрутизаторы 224.0.0.5-224.0.0.6 OSPFIGP (MOSPF) 224.0.0.9 Маршрутизаторы RIP2 224 0 0 10 IGRP маршрутизаторы 224.0.1.0 VMIP группа менеджеров 224.0.1.1 NTP-network time protocol - сетевая службы времени 224.0.1.6 NSS - сервер имен 224.0 1 7 Audionews - audio news multicast (аудио служба новостей) 224.0.1.9 iMTP (multicast transport protocol) - транспортный протокол муль- тикастинга 224.0.1.10 ;IETF-1-low-audio 224.0.1.11 IETF-1-audio 224.0.1.12 IETF-1-video ;224.1.0.0-224.1.255.255 ST мультикастинг-группы 224 2 0 0 224 2 255 255 Вызовы при мультимедиа- конференциях 232 0.0.0 232.255 255.255 VMVP переходные группы

 

IANA владеет блоком Ethernet адресов, которые в шестнадцатеричном представлении выглядят как 00:00:5е. Это старшие 24 бита Ethernet адреса, означающие, что блок включает адреса в диапазоне от 00.00:5о 00:00.00 до 00:00:5e:ff:ff:ff. IANA отвела половину этого блока для групповых адресов. Установлено правило, что первый байт Ethernet адреса равный 01 указывает на групповой адрес. Это означает, что Ethernet адреса, соответствующие групповым адресам IP, должны находиться в диапазоне от 01:00:5е:00:00:00 до 01:00:5e:7f:ff:ff.

Приведенные здесь выражения используют стандартную последовательность битов для Internet, для сетей CSMA/CD или Token bus, а именно такую, как биты располагаются в памяти. Это как раз то, с чем сталкивается большинство программистов и системных администраторов. IEEE документация использует порядок бит, который используется при передаче. Assigned Numbers RFC предоставляет дополнительные подробности о различиях между этими представлениями. Подобное расположение позволяет 23 битам в Ethernet адресе соответствовать идентификатору группы IP. В процессе преобразования адресов 23 младших бита идентификатора группы помещаются в 23 бита Ethernet адреса (рисунок 54). Старшие 5 бит в идентификаторе группы игнорируются, так как они не уникальны. Каждому Ethernet адресу соответствует 32 различных идентификатора группы. Например, групповой адрес 224.128.64.32 (в шестнадцатеричном представлении еО.80.40.20) и 224.0.64.32 (в шестнадцатеричном представлении еО.00.40.20) оба будут трансформированы в Ethernet адрес 01:00:5е:00:40:20.

Так как подобное сопоставление не уникально, предполагается, что драйвер устройства или IP модуль должен осуществить фильтрацию, так как сетевая плата может получить

Рисунок 54. Соответствие между IP адресами класса D и групповыми адресами Ethernet.

Существует два варианта реализации групповой адресации в сетевых платах, использующиеся в локальных сетях. Одни осуществляют групповую фильтрацию, основанную на значении аппаратного группового адреса, групповой фрейм, который хосту не предназначен. Если сетевая плата не осуществляет адекватную фильтрацию групповых фреймов, драйвер устройства, вполне возможно, должен будет получать все групповые фреймы и сам осуществлять фильтрацию.

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

Осуществить групповой запрос в единственную физическую сеть довольно просто. Отправляющий процесс указывает IP адрес назначения, который является групповым адресом, драйвер устройства конвертирует это в соответствующий Ethernet адрес и отправляет. Принимающие процессы должны указать своим IP модулям, что они хочет получать датаграммы, предназначенные определенному групповому адресу, и драйвера устройств должен каким-либо образом получать эти групповые фреймы. Все это называется "вступлением в группу". (Причина, по которой используется выражение "принимающие процессы" во множественном числе, объясняется тем, что обычно существует несколько получателей, которым предназначено групповое сообщение, либо на одном, либо на разных хостах.) Когда групповая датаграмма получена хостом, копия доставляется всем процессам, которые принадлежат к группе. Это отличается от UDP, где единственный процесс получает входящую персональную UDP датаграмму. Несколько процессов на одном хосте могут принадлежать к одной группе.

Однако сложности растут как снежный ком, когда группа распространяется на несколько сетей, и групповые пакеты должны проходить через маршрутизаторы. Маршрутизаторам необходимо знать, принадлежат ли какие-либо хосты в данной физической сети к определенной группе. Для определения этого, существует протокол, называемый протоколом управления группами Internet (IGMP - Internet Group Management Protocol).

2.3. Назначение протокола IGMP

В этой главе мы рассмотрим протокол управления группами Internet, который используется хостами, маршрутизаторами и коммутаторами, для того чтобы поддерживать групповую рассылку сообщений. Он позволяет всем системам физической сети знать, какие хосты в настоящее время объединены в группы и к каким группам они принадлежат. Эта информация необходима для групповых маршрутизаторов, именно так они узнают, какие групповые датаграммы необходимо перенаправлять и на какие интерфейсы. Не все коммутаторы поддерживают протокол IGMP. Функция, реализующая возможность перехвата и анализа IGMP пакетов, называется "igmp snooping". Именно благодаря анализу проходящих IGMP пакетов, коммутатор узнает, к каким портам подключены абоненты и в каких группах они состоят. В дальнейшем коммутаторы и маршрутизатору, поддерживающие протокол IGMP будем называть групповыми маршрутизаторами.

2.4. Идеология и алгоритм работы протокола IGMP

Как и ICMP, IGMP является частью IP уровня. Так же как ICMP, IGMP сообщения передаются в IP-датаграммах. Протокол IGMP имеет сообщение фиксированного размера, без необязательных данных. На рисунке 55 показана инкапсуляция IGMP сообщения в IP-датаграмму.

Рисунок 55. Инкапсуляция IGMP сообщения в IP датаграмму.

 

На то, что в IP-датаграмме находится IGMP сообщение, указывает величина в поле протокола равная 2.

Вступление в группу

Фундаментальной концепцией для работы группы является то, что процесс вступает в группу с определенным интерфейсом хоста. Членство в группе динамическое: со временем процесс может как вступать, так и выходить из группы. Естественно, процесс должен иметь возможность вступить в группу с указанным интерфейсом. Процесс также может покинуть группу, в которую он до этого вступил. Для вступления в группу и выхода из группы требуется, чтобы какой-либо API на хосте поддерживал групповую рассылку. Используется выражение "интерфейс", потому что членство в группе связано с интерфейсом. Процесс может вступить в одну и ту же группу с разных интерфейсов. Релиз IP, поддерживающий групповую рассылку в Berkeley Unix Стэндфордского университета, детализирует эти изменения сокетов API. Поэтому идентификатор хоста в группе это адрес группы и интерфейс. Хост должен помнить таблицу всех групп, к которым принадлежит хотя бы один процесс, и счетчик обращений, то есть количество процессов, принадлежащих к группе.

IGMP запросы и отчеты

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

1 Хост отправляет первый IGMP отчет, когда первый процесс вступает в группу. Если несколько процессов на данном хосте вступили в одну и ту же группу, отправляется только один отчет, в тот момент, когда процесс первый раз вступил в группу. Отчет посылается на тот же интерфейс, с которым процесс вступил в группу.

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

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

4. Хост отвечает на IGMP запрос посылкой одного IGMP отчета для каждой группы, которая содержит хотя бы один процесс.

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

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

Рисунок 56. IGMP отчеты и запросы.

 

Детали реализации

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

Когда хост получает запрос от маршрутизатора, он не отвечает сразу же, а откладывает ответы на более позднее время. (Мы используем множественное число "ответы", потому что хост должен послать один отчет для каждой группы, которая содержит одного или несколько членов.) Так как несколько хостов могут отправить отчет для одной и той же группы, каждый отправляет свой отчет с задержкой, выбранной случайным образом. Также обратите внимание на то, что все хосты подключенные к одной физической сети получают все отчеты от других хостов, находящихся в той же группе, потому что адрес назначения отчета (рисунок 56) - это групповой адрес. А это, в свою очередь, означает, что если хост отложил момент отправки отчета, однако получил копию того же самого отчета от другого хоста, ответ может быть отменен. Это объясняется тем, что групповому маршрутизатору нет необходимости знать, сколько хостов принадлежит к группе - ему достаточно знать, что по крайней мере один хост принадлежит к группе.

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

Поле времени жизни

На рисунке 56 видно, что поле TTL в отчете и запросе установлено в 1. Это напоминает обычное TTL поле в IP заголовке. Групповая датаграмма с TTL исходно равным 0 не "уйдет" дальше своего хоста. По умолчанию групповые датаграммы рассылаются с TTL равным 1. Это позволяет датаграммам распространяться только в своей подсети. Значение TTL больше единицы может быть установлено групповым маршрутизатором. ICMP ошибка никогда не генерируется в ответ на датаграмму, направляемую на групповой адрес. Групповые маршрутизаторы не генерируют ICMP ошибку "время истекло" (time exceeded), когда значение TTL становится равным 0.

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

Путем увеличения TTL приложение может осуществить расширенный поиск (expanding ring search) конкретного сервера. В этом случае первая групповая датаграмма посылается с TTL равным 1, если ответ не получен, посылается датаграмма с TTL равным 2, затем 3 и так далее. В этом случае приложение определяет положение ближайшего сервера в количествах пересылок. Специальный диапазон адресов 224.0.0.0 - 224.0.0.255 отводится для приложений, которые не будут рассылать групповые запросы дальше чем на одну пересылку. Групповые маршрутизаторы не должны перенаправлять датаграммы с такими адресами назначения, вне зависимости от TTL.

Группа всех хостов (All-Hosts)

На рисунке 56 мы видели, что IGMP запрос от маршрутизатора отправляется на IP адрес назначения 224.0.0.1. Этот адрес называется адресом группы всех хостов (all-hosts). Он имеет отношение ко всем хостам и маршрутизаторам подключенным к физической сети и поддерживающим групповую адресацию. Каждый хост автоматически вступает в эту группу со всеми интерфейсами, которые поддерживают групповую адресацию, при инициализации интерфейса. О членстве в этой группе никогда не сообщается (рассылкой отчетов).

Краткие выводы

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

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

2.5. Формат IGMP-сообщений

В настоящий момент существует три версии этого протокола: IGMP v1 (RFC 1112), IGMP
v2 (RFC-2236), IGMP v3. Наиболее распространена версия 2.

Тип сообщения

Максимальное время ответа

Контрольная сумма

Широковещательный адрес группы

Рисунок 57. Формат протокола IGMP версии 2

В IGMPv2 существуют следующие типы сообщений (таблица 3.2).

 

Таблица 3.2 - Возможные значения поля Туре TYPE Источник Тип сообщения Назначение сообщения 0x11 Маршрутизатор Membership Query Запрос о составе группы 0x16 Узел Membership Report (IGMPv2) Отчет о составе группы   Leave Group

 

Рассмотрим назначение этих сообщений более детально. При подключении к IGMP-группе абонентское устройство посылает в сеть IGMP пакет с типом "Отчет о составе группы", тем самым давая понять, что желает получать пакеты для данной группы. При выходе из группы абонентское устройство посылает в сеть IGMP пакет с типом "Сообщение о выходе из группы". Маршрутизатор периодически посылает в сеть IGMP запрос с типом "Запрос о составе группы" для выяснения состава группы на текущий момент времени. Если ответа от абонентских устройств не последовало, то маршрутизатор отключает эту группу и более не пересылает пакеты для данной группы.

Содержимое поля «Максимальное время ответа» имеет смысл только для сообщений Membership Query. В это поле групповой маршрутизатор, использующий IGMPv2, помещает максимальное время задержки ожидания ответа на сообщение, выраженное в десятых долях секунды. По умолчанию значение поля считается равным 100 (10 сек). В остальных сообщениях это поле не анализируется.

Контрольная сумма (checksum) рассчитывается так же, как контрольная сумма ICMP

Групповой адрес (group address) это IP адрес класса D. В запросе поле группового адреса устанавливается в 0. В отчете оно содержит групповой адрес.