Протокол IGMP

Протокол IGMP (Internet Group Management Protocol — межсетевой протокол управления группами) версии 2, определенный в RFC 2236, работает между хостом и соединенным с ним напрямую маршрутизатором (этот маршрутизатор можно рассматривать как первый маршрутизатор на пути следования входящих дейтаграмм или последний маршрутизатор на пути следования исходящих дейтаграмм). На рис. 4.44 изображены три групповых маршрутизатора, каждый из которых соединен с парой хостов через локальный интерфейс. В данном примере локальный интерфейс связан с локальной сетью, и, как правило, несколько хостов локальной сети являются членами той или иной группы рассылки.

Протокол IGMP предоставляет хосту средство информирования соединенного с ним маршрутизатора о том, что работающее на хосте приложение желает присоединиться к определенной группе рассылки. Учитывая ограниченность сферы действия протокола IGMP хостом и соединенным с ним маршрутизатором, для координирования групповых маршрутизаторов (включая присоединенные маршрутизаторы) в Интернете, очевидно, необходимы другие протоколы. Задачу координирования групповых маршрутизаторов решают протоколы групповой маршрутизации сетевого уровня, такие как PIM, DVMRP и MOSPF, которые мы рассмотрим в подразделах «Общий случай групповой маршрутизации» и «Трупповая маршрутизация в Интернете» данного раздела. Таким образом, групповая рассылка на сетевом уровне в Интернете состоит из двух взаимодополняющих компонентов: протокола IGMP и протоколов групповой маршрутизации.

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

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

Хосты отвечают на сообщение membership_query IGMP-сообщением membership jreport, как показано на рис. 4.45. Хост может также генерировать сообщения membership jreport, не ожидая сообщения membershipjquery от маршрутизатора, когда приложение впервые присоединяется к группе рассылки. Сообщения membership jreport получают маршрутизаторы, а также все хосты, присоединенные к тому же интерфейсу маршрутизатора (например, в случае локальной сети). Каждое сообщение membership jreport содержит групповой адрес той группы, в которую вступил отвечающий хост. Обратите внимание, что маршрутизатору все равно, который из хостов присоединился к данной группе рассылки или даже сколько хостов из данной локальной сети присоединилось к определенной группе. (В любом случае маршрутизатор выполняет ту же самую работу — он должен поддерживать протокол групповой маршрутизации вместе с другими маршрутизаторами, обеспечивая получение многоадресных дейтаграмм соответствующими группами рассылки.) Поскольку маршрутизатор беспокоится лишь о том, принадлежит ли любой из присоединенных к нему хостов к той или иной группе рассылки, в идеальном случае хотелось бы получать не более чем по одному уведомлению о принадлежности к группе (зачем тратить время на обработку идентичных сообщений от множества хостов?). Для этого в протоколе IGMP есть специальный механизм, предназначенный для снижения количества сообщений membershipjreport в том случае, когда несколько присоединенных хостов относятся к одной группе рассылки.

В частности, каждое посланное маршрутизатором сообщение membershipjquery также содержит поле максимального времени отклика (рис. 4.46). Получив сообщение membershipjquery, хост выжидает в течение случайного периода времени в диапазоне от нуля до максимального времени отклика, прежде чем ответить сообщением membership ^report. Если за время ожидания хост заметит, что сообщение membership jreport послал какой-либо другой хост, входящий в данную группу рассылки, он воздерживается от передачи, так как понимает, что маршрутизатор теперь знает о существовании среди его хостов членов данной группы. Такая форма подавления отклика представляет собой разновидность оптимизации производительности — она позволяет хостам избежать передачи излишних сообщений membershipj-eport. Аналогичные механизмы подавления отклика используются в ряде протоколов Интернета, включая надежные транспортные протоколы групповой рассылки.

Четвертый, и последний тип IGMP-сообщений — это сообщение leave_group. Интересно отметить, что это сообщение не является обязательным! Но как тогда маршрутизатор определяет, что в данной локальной сети не осталось хостов, входящих в определенную группу? Ответ на этот вопрос дает IGMP-сообщение membershipjquery. Маршрутизатор приходит к выводу, что в данную группу рассылки более не входят присоединенные к нему хосты, если ни один хост не отвечает на его сообщение membership jquery с конкретным групповым адресом.

Интернет-протоколы, в которых по истечении некоторого интервала времени информация об адресах удаляется, иногда называют протоколами с неустойчивым состоянием (soft state). Таким протоколом является протокол IGMP, в котором информация о наличии членов определенной группы рассылки среди хостов локальной сети удаляется по истечении заданного интервала времени (в данном случае этот интервал задает периодически посылаемое маршрутизатором сообщение membership jquery), если оно не обновляется явно (при помощи посылаемого хостом сообщения membershipj-eport). Утверждается, что протоколами с неустойчивым состоянием проще управлять, нежели протоколами с устойчивым состоянием. Для последних нужны не только механизмы явного добавления или удаления состояний (то есть информации о членстве в группах), но также какие-то средства восстановления в ситуации, когда один из этих механизмов преждевременно завершит работу или вообще выйдет из строя.

Подобно ICMP-сообщениям, сообщения протокола IGMP (см. рис. 4.46) переносятся (инкапсулируются) в IP-дейтаграммах.

Познакомившись с протоколом, предназначенным для присоединения к группам рассылки и для выхода из них, мы лучше можем представить себе применяемую сегодня в Интернете модель обслуживания, основанную на групповой рассылке. В данной модели любой хост может присоединиться к группе рассылки на сетевом уровне. Хост просто посылает соединенному с ним маршрутизатору IGMP-сообщение membership jreport. Этот маршрутизатор, работающий в Интернете совместно с другими маршрутизаторами, вскоре начинает доставлять групповые дейтаграммы пославшему уведомление хосту. Таким образом, присоединением к группе управляет получатель. Отправитель добавлением получателей к группе рассылки не занимается. Он даже не может контролировать состав группы получателей. Аналогично, получатель не может контролировать тех, кто посылает дейтаграммы в группу рассылки. Очередность прибытия посылаемых разными хостами дейтаграмм у разных получателей может быть разной. Отправитель-злоумышленник может легко вставлять свои дейтаграммы в поток дейтаграмм групповой рассылки. Даже законопослушные отправители могут случайно выбрать два одинаковых адреса при создании групп рассылки, поскольку координация на сетевом уровне отсутствует. С точки зрения приложения, использующего групповую рассылку, это приведет к тому, что оно «вперемешку» будет принимать дейтаграммы сразу из двух потоков вместо одного.

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

Применяемая сегодня в Интернете модель обслуживания, основанная на групповой рассылке, во многом отражает ту же философию, что и модель обслуживания выборочной рассылки — предельно простой сетевой уровень с дополнительными службами, предоставляемыми протоколами более высокого уровня на хостах. Такая философия в случае выборочной рассылки была, несомненно, успешной. Вопрос о том, может ли подобный подход с максимально упрощенным сетевым уровнем быть таким же успешным для службы групповой рассылки, до сих пор остается открытым.