RFC 1112 Host Extensions for IP Multicasting

Опубликовано 31.08.1989 автором Nikolai Malykh 
Network Working Group                                     S. Deering
Request for Comments: 1112                       Stanford University
Obsoletes: RFCs 988, 1054                                August 1989

Расширение IP Multicasting

Host Extensions for IP Multicasting

PDF

1. Статус документа

Этот документ описывает расширение программ хостов IP для поддержки групповой адресации (multicasting) и является рекомендуемым стандартом IP multicasting для сети Internet. Документ может распространяться свободно.

2. Введение

IP multicasting – это передача дейтаграммы IP группе хостов, содержащей некоторое число (0 или больше) хостов, с использованием одного IP-адреса получателя для всей группы. Групповые (multicast) дейтаграммы доставляются всем членам группы с таким же уровнем надежности (best-efforts – с приложением возможных усилий), как и обычные (unicast) дейтаграммы IP (т. е., не гарантируется доставка дейтаграмм каждому члену группы и сохранение порядка доставки дейтаграмм).

Принадлежность хостов к группе является динамической – хост может присоединиться к группе или выйти из нее в любой момент. На расположение или число членов группы не накладывается каких-либо ограничений. Хост может быть одновременно членом нескольких групп. Для передачи дейтаграмм группе хост не обязан входить в эту группу.

Группа хостов может быть постоянной (permanent) или временной (transient). Постоянная группа включает известные (well-known) IP-адреса, выделяемые администратором. Постоянными являются адреса, а не членство в группе, т. е., постоянная группа может включать произвольное число членов (в том числе, 0). Адреса IP multicast, которые не зарезервированы для постоянных групп, могут использоваться для динамического распределения между временными группами, которые существуют только до тех пор, пока в такой группе есть хотя бы один член.

Межсетевая рассылка групповых дейтаграмм IP обслуживается специальными маршрутизаторами (multicast router), которые могут совмещаться с традиционными маршрутизаторами или функционировать самостоятельно. Хост передает групповую дейтаграмму IP с использованием групповой адресации локальной сети – такие дейтаграммы доставляются всем членам группы в локальной сети. Если дейтаграмма IP имеет время жизни более 1, multicast-маршрутизаторы, подключенные к локальной сети, принимают на себя ответственность за пересылку этой дейтаграммы во все остальные сети, где имеются члены данной группы. В локальных сетях других членов группы, достижимых при заданном времени жизни, подключенный к локальной сети multicast-маршрутизатор завершает пересылку дейтаграммы, используя групповую адресацию локальной сети.

В этом документе рассматриваются требования к реализации хостов IP для поддержки IP multicasting. Под хостом в данном случае понимается любой хост Internet или шлюз, не являющийся multicast-маршрутизатором. Алгоритмы и протоколы, используемые на multicast-маршрутизаторах и между ними, прозрачны для хостов и рассмотрены в отдельных документах. В этом документе не обсуждается групповая адресация в локальных сетях, хотя в качестве примера рассмотрен интерфейс с ЛВС Ethernet и приведены к интерфейсам для ЛВС других типов. Спецификации групповой адресации для разных типов ЛВС будут рассмотрены в других документах.

3. Уровни соответствия

Существует три уровня соответствия данной спецификации:

Уровень 0: без поддержки IP multicasting.

На сегодняшний день1 поддержка IP multicasting не требуется от всех реализаций IP. В общем случае на хосты уровня 0 групповая передача просто не будет оказывать никакого влияния. Однако в некоторых ЛВС присутствие хостов уровней 1 или 2 может приводить к ошибочной доставке групповых дейтаграмм IP хостам уровня 0. такие дейтаграммы легко обнаруживаются по наличию адреса класса D в поле получателя; хостам, не поддерживающим групповой адресации, следует отбрасывать такие дейтаграммы. Адреса класса D описаны ниже (4. Групповая адресация хостов).

Уровень 1: поддерживается только передача групповых дейтаграмм IP.

Уровень 1 позволяет хостам использовать часть возможностей групповой адресации (например, поиск ресурсов или передача отчетов о состоянии), но не позволяет хостам включаться в группы. Реализация IP может быть обновлена с уровня 0 до уровня 1 путем простого добавления нового кода. К реализациям уровня 1 применимы только главы 4, 5, и 6 данной спецификации.

Уровень 2: полная поддержка IP multicasting.

Уровень 2 позволяет хостам включаться в группы и выходить из них, а также передавать дейтаграммы группам хостов. Этот уровень требует реализации протокола IGMP (Internet Group Management Protocol – протокол управления группами) и расширения IP, а так же интерфейса с локальной сетью. К уровню 2 применимы все требования данной спецификации.

4. Групповая адресация хостов

Группы хостов обозначаются адресами класса D (старшие 4 бита имеют значения 1110 – 224). Адреса класса E, у которых 4 старших бита имеют значения 1111 (240), зарезервированы для использования в новых режимах адресации.

В стандартной нотации Internet групповые адреса занимают диапазон от 224.0.0.0 до 239.255.255.255. Адрес 224.0.0.0 не может быть присвоен какой-либо группе, а 224.0.0.1 используется для перманентной группы из всех хостов IP (включая маршрутизаторы) all-hosts. Этот адрес служит для групповой рассылки всем хостам подключенных напрямую сетей. Не существует группового (или иного) адреса для обозначения всех хостов Internet. Адреса хорошо известных перманентных групп публикуются в документах Assigned Numbers2.

В Приложении II более подробно рассмотрены некоторые аспекты групповой адресации.

5. Модель реализации хоста IP

Расширение для поддержки групповой адресации хостами IP задается в терминах описанной выше трехуровневой модели. В рамках модели предполагается, что на хосте (модуль IP) реализованы протоколы ICMP и IGMP (для хостов уровня 2), а отображение адресов IP на адреса ЛВС обеспечивается модулем локально сети. Эта модель используется для наглядности и совершенно не обязательна для конкретных реализаций.

         |                                                          |
         |              Модули вышележащего протокола               |
         |__________________________________________________________|

      --------------------- Интерфейс службы IP -----------------------
          __________________________________________________________
         |                            |              |              |
         |                            |     ICMP     |     IGMP     |
         |                            |______________|______________|
         |           Модуль IP                                      |
         |                                                          |
         |__________________________________________________________|

      ----------------- Интерфейс с локальной сетью -------------------
          __________________________________________________________
         |                            |                             |
         |          Модули            |Сопоставление IP с локальными|
         |          локальной         |адресами (например, ARP)     |
         |          сети              |_____________________________|
         |      (например, Ethernet)                                |
         |                                                          |

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

6. Передача групповых дейтаграмм IP

6.1. Расширение сервисного интерфейса IP

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

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

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

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

6.2. Расширение модуля IP

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

Если IP-адресат находится в той же локальной сети,
   передать дейтаграмму локально IP-адресату
иначе
   передать дейтаграмму локально шлюзу GatewayTo(IP-адресат)

Для поддержки групповой адресации логика маршрутизации должна быть изменена:

Если IP-адресат находится в той же ЛВС или является группой хостов,
   передать дейтаграмму локально IP-адресату
иначе
   передать дейтаграмму локально шлюзу GatewayTo(IP-адресат)

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

Для реализаций уровня 2 IP-адрес отправителя исходящей дейтаграммы должен быть одним из индивидуальных (не групповых) адресов выходного интерфейса.

Адрес группы никогда не помещается в поле отправителя, а также поля source route или записи маршрута в исходящих дейтаграммах IP.

6.3. Расширение интерфейса с локальной сетью

Сервисный интерфейс локальной сети для поддержки групповой адресации IP менять не требуется. Модуль IP просто указывает адрес группы IP вместо адреса конкретного хоста и использует обычную операцию Send Local.

6.4. Расширение модуля Ethernet

Технология Ethernet поддерживает групповую рассылку пакетов в ЛВС и использованием multicast-адреса в поле получателя заголовков Ethernet. Все: что требуется для поддержки передачи групповых дейтаграмм IP – это процедура отображения IP-адреса группы хостов на multicast-адрес Ethernet.

IP-адрес группы отображается на multicast-адрес Ethernet путем помещения 23 младших битов адреса IP в 23 младших бита multicast-адреса Ethernet 01-00-5E-00-00-00 (шестнадцатеричный). Поскольку значащая часть группового адреса IP содержит 28 битов, несколько групп хостов могут отображаться на один multicast-адрес Ethernet.

6.5. Расширение модулей ЛВС для других типов локальных сетей

ЛВС других типов (такие, как кольца и шины, соответствующие стандарту IEEE 802.2), которые непосредственно поддерживают групповую адресацию, могут передавать групповые дейтаграммы IP так же, как это делается в сетях Ethernet. Для сетей, поддерживающих широковещание (broadcast), но не поддерживающих групповой адресации (multicast), типа Experimental Ethernet, все адреса групп IP могут отображаться на один локальный широковещательный адрес (с соответствующим ростом расхода полосы на передачу широковещательных пакетов). Для каналов «точка-точка», соединяющих пары хостов (или хост с multicast-маршрутизатором), групповые пакеты передаются точно так же, как обычные (unicast). Для сетей с промежуточной буферизацией (store-and-forward), типа ARPANET или публичных сетей X.25, все адреса групп IP могут отображаться на хорошо известные локальные адреса multicast-маршрутизаторов IP; маршрутизатор в таких сетях принимает на себя ответственность за дальнейшую доставку дейтаграмм.

7. Прием групповых дейтаграмм IP

7.1. Расширение сервисного интерфейса IP

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

JoinHostGroup(group-address, interface) – присоединиться к группе;
LeaveHostGroup(group-address, interface) – выйти из группы.

Операция JoinHostGroup запрашивает включение хоста в группу, указанную параметром group-address на заданном сетевом интерфейсе. Операция LeaveGroup запрашивает исключение хоста из группы, указанной параметром group-address на заданном сетевом интерфейсе. Указание интерфейса необязательно для хостов, поддерживающих единственный интерфейс. Для хостов, подключенных к нескольким сетям, протокол вышележащего уровня может не указывать интерфейс и в этом случае запрос будет отнесен к используемому по умолчанию интерфейсу (см. 6.1. Расширение сервисного интерфейса IP).

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

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

7.2. Расширение модуля IP

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

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

Входящие дейтаграммы IP со временем жизни 1 не отбрасываются (т. е., такие дейтаграммы не могут быть пересланы, но могут использоваться локально). Входящие дейтаграммы с IP-адресом группы в поле отправителя отбрасываются без генерации сообщений. Сообщения об ошибках ICMP (Destination Unreachable, Time Exceeded, Parameter Problem, Source Quench, Redirect) в ответ на сообщения, адресованные группе хостов IP, никогда не генерируются.

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

Кроме того, в модуль IP должна быть добавлена поддержка протокола IGMP (см. Приложение I. Протокол управления группами IGMP). Протокол IGMP служит для уведомления соседних multicast-маршрутизаторов об участии в группах хостов конкретной локальной сети. Для поддержки IGMP каждый хост уровня 2 должен присоединяться к группе all-hosts (все хосты) с адресом 224.0.0.1 на каждом сетевом интерфейсе при инициализации и сохранять принадлежность к этой группе в течение всего периода активности хоста3.

7.3. Расширение интерфейса с локальной сетью

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

JoinLocalGroup(group-address)
LeaveLocalGroup(group-address)

где group-address задает адрес группы хостов IP. Операция JoinLocalGroup просит модуль локальной сети принимать и доставлять на вышележащий уровень принимаемые впоследствии пакеты, адресованные данной группе хостов IP. Операция LeaveLocalGroup говорит модулю локальной сети о прекращении доставки вышележащему уровню пакетов, адресованных данной группе хостов IP. Предполагается, что модуль ЛВС отображает адреса IP для групп хостов в адреса ЛВС, как это требуется для обновления фильтров групповых пакетов. Любой модуль локальной сети может игнорировать запросы LeaveLocalGroup и продолжать доставку пакетов по большему числу адресов, нежели требуется в соответствии с запросами JoinLocalGroup, если модуль локальной сети не может адекватно фильтровать входящие пакеты.

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

7.4. Расширение модуля Ethernet

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

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

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

7.5. Расширение модулей ЛВС для других типов локальных сетей

Другие сети с поддержкой групповой адресации (например, сети IEEE 802.2) могут обслуживаться так же, как сети Ethernet с точки зрения приема групповых дейтаграмм IP. Для сетей, поддерживающих только широковещание (например, Experimental Ethernet), все входящие широковещательные пакеты следует воспринимать и передавать модулю IP для фильтрации по адресам IP. В сетях point-to-point и store-and-forward групповые дейтаграммы IP будут приходить как unicast-дейтаграммы и каких-либо изменений модуля ЛВС не требуется.

Приложение I. Протокол управления группами IGMP

Протокол IGMP (Internet Group Management Protocol) используется хостами IP для передачи сведений о принадлежности хостов к группам всем multicast-маршрутизаторам в ближайшем окружении (прямым соседям). Протокол IGMP является асимметричным4 и рассматривается, прежде всего, с точки зрения хостов, а не multicast-маршрутизаторов.

Подобно ICMP, протокол IGMP является составной частью IP. Поддержка этого протокола требуется от всех хостов, соответствующих уровню 2 групповой адресации IP. Сообщения IGMP инкапсулируются в дейтаграмм IP с номером 2 в поле протокола. Все сообщения IGMP, относящиеся к хостам, имеют формат:

0

1

2

3

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

Version

Type

Unused

Checksum

Group Address

Version

Номер версии протокола IGMP. В соответствии с данной спецификацией используется версия 1, а описанная в RFC-988 версия 0 считается устаревшей.

Type

Тип сообщения IGMP. К хостам имеют отношение два типа сообщений:

1 = Host Membership Query – запрос на включение в группу;

2 = Host Membership Report – отчет о принадлежности к группе.

Unused

Это поле не используется и должно иметь нулевое значение при передаче пакетов. На принимающей стороне значение игнорируется.

Checksum

Контрольная сумма, представляющая собой 16-битовое поразрядное дополнение суммы поразрядных дополнений всех октетов сообщения IGMP. При расчете контрольной суммы значение этого поля принимается нулевым.

Group Address

Адрес группы. При передаче сообщений Host Membership Query это поле должно иметь нулевое значение, а в принимаемых сообщениях этого типа – значение поля игнорируется.

В сообщения Host Membership Report поле содержит IP-адрес группы хостов, к которой относится отчет.

Неформальное описание протокола

Multicast-маршрутизаторы передают сообщения Host Membership Query (запросы) для определения принадлежности к группам хостов подключенных к маршрутизатору сетей. Запросы адресуются группе all-hosts (224.0.0.1) и передаются со временем жизни IP TTL = 1.

Хосты отвечают на такие запросы сообщениями Host Membership Reports (отклики), сообщающие о каждой группе, в которую входит хост для сетевого интерфейса, через который поступил запрос. Для предотвращения одновременной передачи множества откликов используют два метода:

  1. При получении запроса хост вместо незамедлительной передачи отклика включает таймер для каждой группы, к которой он принадлежит на интерфейсе, через который был принят запрос. Для каждого таймера задается разное время (от 0 до D) с использованием генератора случайных чисел. Когда отсчет заданного времени заканчивается, для соответствующей группы генерируется отклик. Таким образом, отклики передаются в течение D вместо одновременной передачи откликов для всех групп.
  2. Отклики передаются с IP-адресом получателя, совпадающим с адресом группы хостов, к которой относится отчет, и временем жизни 1, поэтому отклик доступен всем членам группы. Если хост видит отчет для группы, в которую он входит, хост останавливает свой таймер для этой группы и не генерирует для нее отклика. Таким образом, в нормальной ситуации, для каждой группы генерируется только один отчет (хостом, на котором установлено минимальное значение таймера для данной группы). Отметим, что multicast-маршрутизаторы получают все групповые дейтаграммы IP и, следовательно, не требуется прямой адресации к таким маршрутизаторам. Отметим также, что маршрутизатору не требуется знать, какие хосты входят в группу – достаточно иметь информацию о присутствии в группе хотя бы одного хоста данной сети.

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

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

Хосту следует подтверждать, что IP-адрес группы хостов в полученном отчете совпадает с полем IP-адреса получателя и полем адреса группы IGMP для того, чтобы собственные отчеты хост не трактовал как ошибочные. Хосту следует без уведомления отбрасывать сообщения IGMP, тип которых отличается от Host Membership Query или Host Membership Report.

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

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

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

Диаграмма состояний

Поведение IGMP формально описывается приведенной ниже диаграммой состояний. Хост может находиться в одном из трех возможных состояний применительно к любой группе хостов IP на любом из сетевых интерфейсов:

  • Состояние Non–Member (хост не входит в группу) – начальное состояние для всех групп на всех сетевых интерфейсах. Это состояние не требует ресурсов хоста.
  • Состояние Delaying Member говорит о том, что хост принадлежит к группе на данном интерфейсе и запущен таймер генерации отчета о принадлежности к группе.
  • Состояние Idle Member говорит о том, что хост входит в группу, но таймер генерации отчета о принадлежности к группе не запущен.

Существует пять типов событий, которые могут вызывать изменения состояний IGMP:

  • Событие join group (подключение к группе) связано с решением хоста о подключении к группе на данном интерфейсе. Это событие может быть связано только с хостами, находящимися в состоянии Non-Member.
  • Событие leave group (выход из группы) происходит в тех случаях, когда хост покидает группу на данном интерфейсе. Это событие может происходить только для хостов, находящихся в состоянии Delaying Member или Idle Member.
  • Событие query received (получен запрос) связано с получением хостом корректного сообщения IGMP Host Membership Query. Корректное сообщение Query должно иметь размер не менее 8 октетов, корректную контрольную сумму IGMP и IP-адрес получателя 224.0.0.1. Одно сообщение Query применимо ко всем фактам принадлежности (membership) на интерфейсе, из которого получено сообщение Query. Это сообщение игнорируется хостами, находящимися в состоянии Non-Member или Delaying Member.
  • Событие report received связано с получением хостом корректного сообщения IGMP Host Membership Report (сообщение должно иметь размер не менее 8 октетов, корректную контрольную сумму IGMP и одинаковый адрес IP в поле получателя и адреса группы IGMP). Сообщение Report применимо только к принадлежности к группе, указанной в данном сообщении и относящейся к интерфейсу, через который принято сообщение Report. Это сообщение игнорируется хостами, находящимися в состоянии Non-Member или Delaying Member.
  • Событие timer expired происходит при завершении времени, заданного для таймера задержки этой группы на данном интерфейсе. Событие может происходить только в состоянии Delaying Member.

Все прочие события (например, некорректные сообщения IGMP или сообщения IGMP, не являющиеся Query или Report) игнорируются в любом состоянии.

В ответ на перечисленные выше события может выполняться три типа операций:

  • Передача отчета (send report) для группы на данном интерфейсе.
  • Запуск таймера (start timer) для группы на данном интерфейсе с использованием случайной задержки в диапазоне от 0 до D секунд.
  • Остановка таймера (stop timer) для группы на данном интерфейсе.

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

                    |----------------|
                    |                |
          --------->|   Non-Member   |<---------
         |          |                |          |
         |          |----------------|          |
         |                   |                  |
         | выход из группы   |включение в группу| выход из группы
         | (stop timer)      |(send report,     |
         |                   | start timer)     |
 ________|________           |          ________|________
|-----------------|<---------          |-----------------|
|                 |                    |                 |
|                 |<-------------------|                 |
|                 | принят запрос      |                 |
| Delaying Member | (start timer)      |  Idle Member    |
|                 |------------------->|                 |
|                 | принят отчет       |                 |
|                 | (stop timer)       |                 |
|-----------------|------------------->|-----------------|
                    отсчет завершен
                    (send report)

Группа all-hosts (адрес 224.0.0.1) рассматривается как специальный случай. Хост стартует в состоянии Idle Member по отношению к этой группе на всех интерфейсах, никогда не переходит в другие состояния и никогда не шлет сообщений о принадлежности к этой группе.

Параметры протокола

Максимальная задержка передачи отчета (D) составляет 10 секунд.

Приложение II. Вопросы групповой адресации

Это приложение не является частью спецификации IP multicasting и служит для разъяснения некоторых вопросов, связанных с адресацией групп хостов IP.

Привязка групповых адресов

Привязка групповых адресов IP к конкретным хостам может рассматриваться как обобщение привязки обычных (unicast) адресов IP. Обычный адрес IP статически связывается с локальным сетевым интерфейсом в одной сети IP. Групповые IP-адреса динамически связываются с множеством сетевых интерфейсов с различных сетях IP.

Важно понимать, что групповой адрес IP не связывается с набором обычных (unicast) адресов IP. Multicast-маршрутизаторам не нужно поддерживать списки отдельных членов каждой группы. Например, маршрутизатору, подключенному к сети Ethernet, достаточно связать по одному групповому адресу Ethernet с каждой группой, в которую входят хосты локальной сет, и не нужно поддерживать списки адресов IP или Ethernet для всех членов групп.

Распределение адресов для временных групп

В этом документе не рассматриваются вопросы распределения адресов для временных групп. Предполагается, что разные части пространства адресов IP, выделенного для временных групп, могут распределяться с использованием разных методов. Например, может существовать множество служб, которые будут продавать адреса для новых временных групп. Некоторые протоколы верхних уровней (типа протокола VMTP, описанного в RFC-1045) могут порождать временные адреса process group (группа процессов) или entity group (группа объектов), которые алгоритмически отображаются на подмножество адресов временных групп хостов IP (подобно отображению групповых адресов IP в групповые адреса Ethernet). Часть пространства групповых адресов IP может сохраняться для произвольного распределения между приложениями, которые устойчивы к возникновению конфликтов с другими группами на почве распределения адресов (например, путем выбора нового адреса из числа доступных).

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

Адрес автора

Steve Deering

Stanford University

Computer Science Department

Stanford, CA 94305-2140

Phone: (415) 723-9427

EMail: deering@PESCADERO.STANFORD.EDU

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

 

1 1989 год. Прим. перев.

2 В настоящее время текстовые варианты этих документов утратили силу и взамен используется база данных, доступная по ссылке www.iana.org/numbers.html. Прим. перев.

3 Дейтаграммы, адресованные в группу all-hosts трактуются multicast-маршрутизаторами как специальный случай групповых дейтаграмм и никогда не пересылаются за пределы одной сети, независимо от заданного времени жизни дейтаграмм. Таким образом, адрес all-hosts не может использоваться в качестве адреса глобальной широковещательной рассылки. Для протокола IGMP принадлежность к группе all-hosts реально требуется лишь до тех пор, пока хост входит по крайней мере в дну из реальных групп. Однако спецификация протокола требует сохранения принадлежности к этой группе по нескольким причинам: (1) так проще, (2) частота получения избыточных запросов IGMP должна быть достаточно мала во избежание чрезмерной загрузки сети (3) адрес all-hosts может использоваться для других, связанных с маршрутизацией, целей (например, для анонсирования присутствия шлюзов или обнаружения локальных адресов.

4 Протокол IGMP может также использоваться для обмена информацией (симметричного или асимметричного) между multicast-маршрутизаторами, но этот аспект протокола здесь не рассматривается.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.