Компьютерные сети

Оповещение маршрутизатора о желании хоста быть включенным в группу. Чтобы стать получателем групповых данных, узел должен «выразить» свою заинтересованность маршрутизатору, к которому непосредственно подсоединена его сеть. Для этого хост должен установить взаимодействие с маршрутизатором по протоколу IGMP. Версия IGMP для хоста прямо зависит от типа операционной системы, установленной на хосте. Так, ранние версии Windows (Windows 95) поддерживали только версию IGMPvl, более поздние (Windows 2000) — версию IGMPv2, а начиная с Windows ХР, поддерживается версия IGMPv3. Протоколы IGMPv2 и IGMPv3 поддерживаются во многих версиях Mac OS, Linux, Unix-подобных операционных системах.

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

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

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

□ Покинуть группу (leave group). Это сообщение хост может использовать, чтобы сигнализировать «своему» маршрутизатору о желании покинуть некоторую группу, в которой он до этого состоял. Получив это сообщение, маршрутизатор посылает специфический запрос о членстве членам только этой конкретной группы, и если не получает на него ответ (то есть это был последний хост в группе), то перестает передавать трафик группового вещания для этой группы. Слово «может» означает в данном случае, что хост может быть исключен из группы, просто не отвечая маршрутизатору на запрос о членстве (такой подход реализован в протоколе IGMPvl). Тогда маршрутизатор будет продолжать передавать нежелательный трафик группового вещания до тех пор, пока не истечет некоторый период времени с момента поступления последнего отчета о членстве. Такой подход может значительно удлинить период скрытого нахождения хоста в состоянии выхода из группы, что снижает эффективность работы сети.

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

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

Основываясь на информации, полученной с помощью IGMP, маршрутизаторы могут определять, в какие подключенные к ним сети необходимо передавать групповой трафик.
Все типы IGMP-сообщений имеют длину 8 байт и состоят из четырех полей. В зависимости от версии протокола IGMP назначение полей может несколько меняться. На рис. 18.14 показана структура сообщения для версии IGMPv2.
1-4 байты
Тип
Максимальное
Контрольная
сообщения
время ответа
сумма
Адрес группового
5-8 байты
вещания

(Multicast group address)
Рис. 18.14. Структура IGMP-сообщения
Поле максимального времени ответа используется хостами для вычисления времени задержки ответа. Время задержки выбирается случайным образом из интервала от нуля до значения, заданного в этом поле.

Заметим, что поле адреса группового вещания в IGMP-сообщении не содержит адрес назначения, оно несет в себе информацию, по-разному используемую в разных типах сообщений. Например, маршрутизатор, посылая запрос о членстве, помещает в этом поле нули, а хост в сообщениях «Отчет о членстве» и «Покинуть группу» помещает в это поле адрес группы, в которую он хочет вступить или которую он хочет покинуть соответственно.
ПРИМЕЧАНИЕ-

Чтобы хост смог получать трафик группового вещания, недостаточно установить на нем протокол IGMP, с помощью которого хост может отправить сообщение своему маршрутизатору о желании присоединиться к группе. Помимо этого, надо сконфигурировать сетевой интерфейс хоста так, чтобы он стал захватывать из локальной сети кадры, несущие в себе пакеты группового вещания для той группы, к которой присоединился хост. Для этого необходимо настроить интерфейс на прослушивание определенного группового адреса канального уровня, соответствующего групповому IP-адресу. К сожалению, адресное пространство групповых IP-адресов в 32 раза объемнее пространства групповых М AC-адресов. То есть отображение этих двух адресных пространств оказывается далеко неоднозначным — на один и тот же групповой МАС-адрес отображается целый блок из 32 различных групповых IP-адресов. Следовательно, когда сетевой адаптер захватывает кадр, содержащий пакет группового вещания, существует значительная вероятность того, что этот пакет был направлен совсем другой группе. Однако эта ошибка скоро обнаруживается. Когда кадр передается вверх по стеку, протокол IP проверяет, совпадает ли групповой IP-адрес в поле адреса назначения инкапсулированного пакета с групповым IP-адресом данного интерфейса. (Отметим, что ни групповые IP-адреса, ни групповые МАС-адреса никогда не используются в качестве адресов отправителя.)

Принципы маршрутизации трафика группового вещания
Среди принципов маршрутизации трафика группового вещания можно отметить:
□ маршрутизацию на основе доменов;
□ учет плотности получателей группового трафика;
□ два подхода к построению маршрутного дерева;
□ концепцию продвижения по реверсивному пути.

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

Учет плотности получателей группового трафика. Внутридоменные протоколы маршрутизации разделяются на два принципиально отличных класса:

□ Протоколы плотного режима (Dense Mode, DM) разработаны в предположении, что в сетевом домене существует большое число принимающих узлов. Отсюда следует главная идея этих протоколов: сначала «затопить» сеть пакетами группового вещания по всем направлениям, останавливая продвижение пакетов, лишь когда находящийся на пути распространения трафика маршрутизатор явно сообщит, что далее ниже по потоку членов данной группы нет.

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

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

ПРИМЕЧАНИЕ-
Сейчас согласно общепринятому мнению предпочтительнее применять протоколы разряженного режима даже в тех ситуациях, когда плотность приемников достаточно высока.

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

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

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

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

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

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

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

Проверка факта выполнения данного условия называется продвижением по реверсивному пути (Reverse Path Forwarding, RPF). Такое название объясняется тем, что эта процедура связана не столько с путями, ведущими вперед от текущего места нахождения пакета к пункту назначения, сколько с обратным (реверсивным) путем, который уже пройден пакетом от того места, где он находится сейчас, до источника. Только пакеты, которые прошли RPF-проверку, являются кандидатами для дальнейшего продвижения вдоль путей, ведущих к потенциальным получателям трафика группового вещания.

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

На этом этапе мы йе предъявляли специфических требований к таблицам маршрутизации, на основании которых выполняется RPF-проверка. Некоторые протоколы, такие как DVMRP, строят собственную таблицу маршрутизации, в то время как, например, протокол PIM работает с таблицами маршрутизации, построенными другими протоколами.
Протокол DVMRP

Дистанционно-векторный протокол маршрутизации группового вещания (Distance Vector Multicast Routing Protocol, DVMRP), описанный в спецификации RFC 1075, может быть характеризован с самых общих позиций следующим образом:
□ как следует из его названия, он основан на дистанционно-векторном алгоритме и, следовательно, обладает всеми особенностями, свойственными данному алгоритму;
□ относится к классу протоколов плотного режима, использующих проверку продвижения по реверсивному пути;

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

Протокол DVMRT был одним из первых протоколов продвижения группового трафика в исследовательской сети МВопе. Групповая маршрутизация в ранней версии МВопе была, в сущности, управляемой формой широковещания, когда пришедший пакет с групповым адресом передавался через все интерфейсы, кроме входного. Для борьбы с зацикливанием пакетов с групповыми адресами маршрутизаторы запоминали факт продвижения данного пакета и при его поступлении в следующий раз просто отбрасывали. Для сокращения бесполезного трафика в сети применялся протокол IGMR С помощью этого протокола маршрутизаторы выясняли, имеются ли в непосредственно подключенных к нему сетях конечные узлы, принадлежащие к определенной группе, или нет. В том случае, когда маршрутизатор определял, что к некоторому интерфейсу подключена сеть, в которой нет членов группы, являющихся получателями группового пакета, он не передавал копию этого пакета чрез данный выходной интерфейс.

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

Рис. 18.15. Управляемое широковещание
Чтобы модернизировать протокол DVMPR, понадобилось несколько лет дополнительных усилий.
Цель модернизации состояла в распространении группового трафика от источника к получателям таким образом, чтобы пакеты продвигались только по тем путям, которые единственным и кратчайшим образом соединяли источник с каждым получателем.

Такие пути образуют дерево с вершиной в источнике, соединяющее кратчайшими путями все маршрутизаторы, к которым непосредственно подключены локальные сети, содержащие получателей данной группы, с маршрутизатором, к которому непосредственно подсоединена сеть, содержащая источник. Дерево для источника S и членов показанной на рисунке группы образуется оставшимися (незачеркнутыми) путями.
ПРИМЕЧАНИЕ-

Для построения деревьев с вершиной в источнике пригодны различные алгоритмы, в частности один из таких алгоритмов, разработанный и стандартизованный IEEE для мостов локальных сетей под названием STA, мы рассмотрели ранее в главе 14.

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

Результирующее дерево называется деревом реверсивного кратчайшего пути. Для его
построения необходимо выполнить следующие действия:
1. Источник отправляет пакет по своей локальной сети с групповым адресом. Присоединенный к локальной сети маршрутизатор получает пакеты и отправляет их на все выходные интерфейсы.

2. Каждый маршрутизатор, который получает пакеты, выполняет RPF-проверку. Маршрутизатор принимает пакеты по некоторому интерфейсу только в том случае, если считает, что через него проходит самый эффективный обратный путь к источнику. Все пакеты, принимаемые с «правильного» интерфейса, продвигаются на все выходные интерфейсы. Все остальные просто отбрасываются.

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

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

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

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