Протокол 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

Destination	Source	UpStream	DownStream	TTL
224.1.1.1	128.1.0.2		2,3
224.1.1.1	128.4.1.2		2,3
224.1.1.1	128.5.2.2		2,3
224.2.2.2	128.2.0.3

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-07-13