Протоколы групповой маршрутизации

Протокол DVMRP

Версия 1 протокола DVMRP (Distance Vector Multicast Routing Protocol) опи­сана в документе RFC 1075. Этот протокол основан на протоколе RIP и алго­ритме TRPB. Основное отличие между протоколами RIP и DVMRP состоит в том, что первый нацелен на определение следующего транзитного узла на пути к получателю, а второй — на определение предыдущего транзитного узла на пути к отправителю. Протокол DVMRP предназначен для передачи группового трафика через распределенную сеть и использует алгоритм вектора расстояния. Протокол строит дерево доставки на основе несколько модифицированного ал­горитма RPB. Однако ведущие поставщики маршрутизаторов в своих последних изделиях наряду с алгоритмом RPB используют алгоритм RPM. Поэтому ны­нешняя реализация протокола DVMRP немного отличается от оригинальной спецификации RFC.

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

Маршрутизатор передает дейтаграммы с групповым адресом через свои пор­ты, если значения поля TTL в заголовках дейтаграмм больше, чем значения, указанные для портов. Это служит для ограничения зоны действия групповой передачи дейтаграмм. В табл. 9.3 перечислены наиболее часто используемые значения TTL.

Таблица 9.3. Типичные значения TTL

Как уже было сказано, протокол DVMRP использует алгоритм RPM. Напом­ним, что в соответствии с этим алгоритмом, первая дейтаграмма с групповым адресом для любой пары (отправитель, группа-получатель) передается через всю распределенную сеть. Эта дейтаграмма поступает ко всем маршрутизаторам в сети, которые высылают усекающие сообщения в случае, если в подключенных к ним подсетях нет членов группы-получателя. В результате происходит усече­ние дерева доставки от источника. После некоторого промежутка времени про­исходит проверка правомерности усечения: усеченные части дерева «реабилитируются», следующая дейтаграмма для пары вновь передается через всю распределенную сеть, и усечение определяется заново.

Протокол DVMRP реализует механизм быстрого восстановления усеченных частей дерева доставки. Если маршрутизатор, ранее отвечавший усекающими сообщениями для пары (отправитель, группа-получатель), вдруг обнаружил новых членов группы-получателя в подключенных подсетях, он посылает вос­станавливающее сообщение (graft). Это позволяет восстановить усеченную часть дерева доставки, не дожидаясь регулярной процедуры обновления.

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

Для иллюстрации сказанного рассмотрим пример (рис. 9.11). Маршрутиза­тор Ml может получать дейтаграммы от отправителя через маршрутизаторы М2 или МЗ. Если у маршрутизатора М2 метрика к сети отправителя меньше, чем у маршрутизатора МЗ, он продолжит передачу трафика от отправителя, а марш­рутизатор МЗ будет отбрасывать трафик, предотвращая тем самым его дублиро­вание. Если метрика маршрутизатора М2 равна метрике МЗ, то доминантным становится маршрутизатор с наименьшим IP-адресом на своем порожденном порте.

Маршрутизаторы в распределенной сети должны поддерживать единичную адресацию и групповой трафик. Два соответствующих процесса на одном из маршрутизаторов будут периодически обмениваться сообщениями об обновле­нии таблиц маршрутизации с соседними маршрутизаторами. Причем такие со­общения являются независимыми от используемого протокола маршрутизации класса IGP. Иными словами, на маршрутизаторе будут работать два процесса: один — для маршрутизации обычного трафика с единичной адресацией, а дру­гой — для группового трафика.

В табл. 9.4 показан пример таблицы маршрутизации, сформированной прото­колом DVMRP. По сравнению с традиционной таблицей (например, для прото­кола RIP) в приведенной таблице содержатся дополнительные поля «Source Subnet» (исходная сеть) и «From-Gateway» (от маршрутизатора). Они заменяют поля «Destination» (получатель) и «Next-Hop Gateway» (следующий маршрути­затор в пути). Таблица маршрутизации протокола DVMRP хранит информацию о кратчайших путях в каждую подсеть распределенной сети, однако членство в группах не учитывается. Кроме того, не учитываются полученные усекающие сообщения.

Таблица 9.4. Таблица маршрутизации протокола DVMRP

Столбцы в этой таблице имеют следующее назначение:

q Source Subnet — IP-адрес сети отправителя групповых дейтаграмм;

q Subnet Mask — маска подсети отправителя. Протокол DVMRP использу­ет маску подсети в каждой сети;

q From Gateway — маршрутизатор, находящийся на одном переходе назад на пути к отправителю;

q TTL — время жизни в секундах (см. выше).

Назначение остальных полей очевидно и не требует пояснения.

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

Таблица 9.5. Передача протокола DVMRP

Столбцы в этой таблице имеют следующее назначение:

q Source Subnet — IP-адрес сети отправителя групповых дейтаграмм;

q Multicast Group — групповой IP-адрес, по которому послана дейтаграмма;

q InPort — родительский порт для данной пары. Параметр (Рr) говорит о том, что через этот порт было послано усекающее сообщение;

q OutPorts — порожденные порты. Параметр (Р) говорит о том, что марш­рутизатор получил через этот порт усекающее сообщение.

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

Для разрешения этой проблемы предназначена иерархическая версия прото­кола DVMRP. При использовании иерархической маршрутизации магистраль MBONE будет разделена на несколько регионов (доменов) маршрутизации. Каждый регион работает со своим протоколом групповой маршрутизации, а для маршрутизации между регионами используются другие протоколы. Иерархичес­кая структура снижает требования к ресурсам маршрутизаторов: каждый маршрутизатор должен поддерживать служебную информацию только о своем регио­не и ему не нужно знать детальную структуру других регионов. Протокол пере­дачи между регионами, в свою очередь, не учитывает внутреннюю топологию регионов.

Каждый регион имеет свой уникальный идентификатор (Region-ID). Марш­рутизаторы внутри регионов могут поддерживать любой существующий группо­вой протокол маршрутизации — DVMRP, MOSPF или PIM. Эти протоколы относятся к протоколам первого уровня (Level I, L1). Каждый регион должен иметь, по крайней мере, один пограничный маршрутизатор, отвечающий за связь между регионами. Такие маршрутизаторы поддерживают протокол DVMRP — протокол второго уровня (Level 2, L2) (рис. 9.12). Они обмениваются между собой идентификаторами регионов, а не адресами подсетей внутри регионов, поэтому протокол DVMRP несколько модифицирован. Он формирует дерево доставки для пары (регион, группа-получатель), а не для обычной пары (отпра­витель, группа-получатель).

Протокол DVMRP — самый распространенный протокол групповой маршру­тизации. Его несложно внедрить, так как он основан на простом известном про­токоле RIP. С другой стороны, именно тот факт, что основой DVMRP является протокол RIP, ограничивает его применение в больших распределенных сетях.

Протокол MOSPF

Во многих распределенных сетях используется другой протокол — MOSPF. Он является расширением известного протокола OSPF. Протокол OSPF частично устраняет основные недостатки RIP (большое время обновления таблиц марш­рутизации и непригодность для крупных распределенных сетей).

Протокол MOSPF описан в документе RFC 1584. Протокол MOSPF позво­ляет маршрутизаторам использовать их базы данных состояния канала (Link State Database) для построения деревьев доставки и для последующей маршру­тизации группового трафика.

Протокол MOSPF задействует протокол IGMP для определения активных членов групп в подключенных подсетях. Для этого ведется специальная база данных, которая управляет списком членов в сетях, подключенных напрямую к маршрутизатору. Рассылку сообщений HMQ протокола IGMP выполняет назначенный маршрутизатор (Designated Router, DR). Кроме того, ответствен­ность за прослушивание сообщений IGMP HMR несут только назначенный и резервный маршрутизаторы (Backup Designated Router, BDR). BDR автомати­чески заменяет DR в случае его выхода из строя.

Как только назначенный маршрутизатор получает информацию о появлении нового члена группы в подключенных к нему подсетях, он генерирует специальное групповое сообщение Group-Membership LSA (Link-State Advertisement), кото­рое доставляется всем маршрутизаторам внутри данной области OSPF. После получения этого сообщения маршрутизатор добавляет информацию о новом члене группы в свою базу данных состояния канала (рис. 9.13).

Алгоритм состояния канала, заложенный в основу протокола MOSPF, позво­ляет маршрутизаторам быстро адаптироваться к изменениям сетевой топологии и членства в группах. По сравнению с DVMRP протокол MOSPF может исполь­зовать при построении дерева доставки от источника более гибкую метрику мар­шрута. Напомним, что протокол RIP учитывает только количество транзитных узлов, протокол OSPF допускает выбор метрики.

Каждый маршрутизатор MOSPF принимает решение о передаче трафика на основе содержимого своей таблицы передачи. Она формируется на основе ин­формации о деревьях доставки от источника для каждой пары и информации локальной базы данных о группах. Таблица передачи составляется после того, как маршрутизатор определяет свое положение в дереве доставки. В табл. 9.6 показан пример таблицы передачи протокола MOSPF.

Таблица 9.6. Таблица передачи протокола MOSPF

Столбцы в этой таблице имеют следующее назначение:

q Destination — адрес группы-получателя;

q Source — сетевой адрес отправителя;

q UpStream — порт маршрутизатора, на который дейтаграмма для этой пары должна быть получена;

q DownStream — порт, через который следует послать дейтаграмму;

q TTL — минимальное число переходов до группы-получателя (напомним, что каждый маршрутизатор уменьшает значение TTL, как минимум, на единицу). Это поле позволяет маршрутизатору удалять дейтаграммы, ко­торые не имеют шансов достигнуть получателя.

Информация в таблице передачи не устаревает с течением времени и не тре­бует периодического обновления. Таблица передачи изменяется при изменениях сетевой топологии или распределения членов группы, о чем информируют груп­повые сообщения LSA.

Выше была рассмотрена обработка группового трафика протоколом MOSPF внутри одной области OSPF. В документе RFC 1584 дополнительно описывают­ся методы передачи группового трафика между областями, доменами и автоном­ными системами.

В распределенной сети протоколы MOSPF и OSPF можно комбинировать. Тем самым протокол MOSPF можно внедрять постепенно. Необходимо учитывать, что при построении деревьев доставки протокол MOSPF ориентируется только на маршрутизаторы, поддерживающие этот протокол; маршрутизаторы OSPF он игнорирует. При этом может выбираться не самый оптимальный маршрут.

Протокол MOSPF лучше всего использовать в распределенных сетях, содер­жащих относительно небольшое количество одновременно активных пар (отпра­витель, группа-получатель). Если в сети много активных пар и линии связи могут время от времени отказывать, высока вероятность снижения производи­тельности протокола.

Протокол РIМ

Протокол РIМ (Protocol-Independent Multicast, групповая маршрутизация, неза­висящая от протокола) был разработан комитетом IETF. Протокол Р1М пол­ностью не зависит от протоколов маршрутизации, использующих обычную схему адресации. Для ведения таблицы маршрутизации и быстрой адаптации к изменениям сетевой топологии используется один из протоколов маршрутиза­ции, относящихся к классу IGP (RIP, NSLP, OSPF и т. д.) или EGP. Протокол Р1М поддерживает два режима работы — Dense Mode (PIM-DM) и Sparse Mode (PIM-SM). Режим PIM-DM применяется при:

q небольшом расстоянии между отправителем и получателями группового трафика;

q небольшом количестве отправителей и большом количестве получателей;

q большом объеме группового трафика;

q постоянном потоке группового трафика.

Протокол Р1М в режиме DM подобен протоколу DVMRP: для построения деревьев доставки оба протокола используют алгоритм RPM. Основное разли­чие между ними заключается в том, что PIM-DM полагается на один из прото­колов маршрутизации класса IGP (или EGP).

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

Так же, как и протокол DVMRP, протокол PIM-DM поддерживает восста­навливающие сообщения, которые позволяют быстро реконструировать усечен­ное дерево доставки.

Режим PIM-SM был разработан для взаимодействия разбросанных в распре­деленной сети членов групп. В таких средах применение алгоритма RPM может привести к снижению пропускной способности сети. Для эффективной марш­рутизации группового трафика в режиме PIM-SM введена концепция точки встречи (Rendezvous Point, RP). Роль такой точки играет один или несколько маршрутизаторов (этот подход аналогичен тому, что применяется в алгоритме СВТ). Вначале отправитель посылает данные на маршрутизатор. Если получа­тель хочет получать эти данные, он должен зарегистрироваться на маршрутиза­торе. После того как групповой трафик передан по схеме «отправитель — точка встречи (маршрутизатор) — получатель», промежуточные маршрутизаторы на пути следования автоматически оптимизируют маршрут для устранения лиш­них транзитных узлов.

Режим Р1М SM применяется в следующих случаях:

q если в группах получателей немного;

q если между отправителем и получателями находится канал связи глобаль­ной сети;

q при непостоянном потоке группового трафика.

Если в сети есть несколько маршрутизаторов PIM, то маршрутизатор с наи­большим IP-адресом станет назначенным (DR). Он отвечает за передачу сооб­щений HMQ протокола IGMP, за посылку усекающих сообщений и сообщений о присоединении и за управление точками встречи.

В табл. 9.7 приведен краткий сравнительный анализ рассмотренных протоко­лов групповой маршрутизации.

Таблица 9.7. Протоколы групповой маршрутизации

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

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

Важно отметить, что все рассмотренные протоколы групповой передачи дан­ных могут эффективно работать в сетях ATM без каких-либо изменений. Конеч­ное оборудование ATM, поддерживающее стандарт LANE (LAN Emulation), прозрачно поддерживает протоколы групповой передачи сетевого уровня.

Рассмотренные протоколы доставки группового трафика работают на сетевом уровне. На канальном уровне при доставке кадров с групповыми адресами могут возникнуть проблемы. Это связано с тем, что подавляющее большинство ло­кальных вычислительных сетей строится на базе коммутаторов, которые после трансляции группового IP-адреса в групповой МАС-адрес воспринимают кадры с групповыми адресами как широковещательные и, соответственно, передают их на все свои порты, вызывая ненужный трафик. Такая схема обработки группо­вого трафика на канальном уровне сводит на нет все преимущества групповой адресации. Кроме того, большинство относительно дешевых коммутаторов игнорируют сообщения протокола IGMP и не способны определить, к каким портам подключены члены групп.

Совместить преимущества групповой передачи данных с использованием коммутаторов локальной сети можно двумя способами. Первый — приобретать более «интеллектуальные» коммутаторы, которые отслеживают проходящий че­рез них трафик протокола IGMP. Такой возможностью, например, обладает вы­сокопроизводительный коммутатор LANPlex фирмы 3Com. Такой коммутатор направляет групповой трафик только на те порты, которые связаны с членами определенных групп.

Второй способ заключается в использовании фирменных технологий отдель­ных поставщиков. Например, фирма Cisco ввела в свои маршрутизаторы и ком­мутаторы поддержку собственного протокола Cisco Group Multicast Protocol (CGMP). Протокол CGMP позволяет коммутаторам использовать информацию, получаемую маршрутизаторами по протоколу IGMP. В результате групповой трафик на канальном уровне передается только на те порты, к которым подклю­чены члены группы-получателя.

Кратко рассмотрим принципы протокола CGMP. Предположим, что на од­ном конце распределенной сети находится отправитель групповых IP-дейта­грамм, а член группы-получателя располагается где-то на другом ее конце. Путь дейтаграмм между маршрутизаторами распределенной сети определяется с по­мощью протоколов групповой маршрутизации. Получатель посылает сообщение IGMP локальному маршрутизатору. Тот сохраняет в памяти МАС-адрес стан­ции, пославшей сообщение, а затем посылает сообщение CGMP коммутатору, к которому подключена группа. Коммутатор использует полученное сообщение для динамического добавления в свою таблицу коммутации полей, определяю­щих порты, соответствующие членам группы-получателя. После этого комму­татор передает групповой трафик на канальном уровне только на те порты, к которым подключены члены группы-получателя.