|
|
|
4.4.9.1 Мультикастинг и MBONE
Семенов Ю.А. (ГНЦ ИТЭФ) |
|
MBONE - это виртуальная сеть, базирующаяся на мультикастинг-протоколах, которые были одобрены IETF летом 1992 года. В основу легли разработки, выполненные в компании Ксерокс. Данный режим работы поддерживается не всеми маршрутизаторами. Сеть представляет собой систему Ethernet-сетей, объединенных друг с другом соединениями точка-точка, которые называются "туннелями". Конечными точками таких туннелей обычно являются машины класса рабочих станций, снабженные соответствующим программным обеспечением. Впервые мультикастинг-туннель был реализован в Стэнфордском университете в 1988 году. IP-мультикастинг-пакеты инкапсулируются при передаче через туннели так, что они выглядят как обычные IP-уникаст-пакеты. Мультикастинг-маршрутизатор при посылке пакета через туннель подготавливает IP-пакет с заголовком, который содержит адрес маршрутизатора-партнера на другом конце туннеля, при этом поле IP-протокола содержит код 4 (IP). Маршрутизатор-приемник извлекает вложенный мультикастинг-пакет и направляет далее, если это требуется. MBONE требует пропускной способности магистральных каналов не ниже 500Kбит/с. Каждый туннель имеет определенный порог для переменной времени жизни пакета (time-to-live - TTL). Согласно договоренности (IETF) широкополосная видео-информация передается с малыми начальными значениями TTL. Малые значения TTL не позволяет видео-пакетам загружать слишком большие участки сети. Мультикастинг-дейтограмма с TTL=0 может быть доступна только процессу, существующему в ЭВМ, породившей эту дейтограмму. По умолчанию мультикастинг-дейтограммы имеют TTL=1, такая дейтограмма не может покинуть пределов субсети, и только дейтограммы с TTL>1 могут переадресовываться маршрутизаторами. Следует помнить, что маршрутизатор не откликнется ICMP-сообщением "время истекло", когда TTL достигнет нуля, так как вообще дейтограммы с мультикастинг-адресами не вызывают ICMP-откликов. Увеличивая TTL, прикладной процесс может расширять "зону взаимодействия". Сначала дейтограмма может посылаться с TTL=1, если отклика не получено, c TTL=2 и так далее. Эта схема позволяет найти ближайший сервер (с точки зрения числа шагов до него). Для приложений, которые ограничивают свою активность в пределах одного шага, предусмотрен специальный интервал адресов 224.0.0.0 - 224.0.0.255. Мультикастинг-маршрутизатор не должен переадресовывать дейтограммы с такими адресами вне зависимости от значения TTL. Адрес 224.0.0.1 является адресом группы "все ЭВМ" и относится ко всем ЭВМ и маршрутизаторам, способным работать в режиме мультикастинга. Каждая ЭВМ автоматически включается в эту группу при инициализации интерфейса. О членстве в этой группе ЭВМ не сообщает. Конфигурация системы в режиме мультикастинга производится автоматически. Для того чтобы изменить конфигурацию системы, или добавить еще один туннель используются специальные конфигурационные команды, которые записываются в /etc/mrouted.conf. Существует два типа таких команд: phyint <local-addr> [disable] [metric <m>] [threshold <t>] tunnel <local-addr> <remote-addr> [metric <m>] [threshold <t>] Первая команда может отменить мультикастинг-маршрутизацию для конкретного физического интерфейса, идентифицируемого по его IP-адресу (<local-addr>), или заменить значение метрики или порога. Эта команда должна выдаваться до команды tunnel. Последняя команда может служить для установления туннеля между местным IP-адресом (<local-addr>) и удаленным IP-адресом (<remote-addr>). Значения метрики и порога по умолчанию равны 1. Специфика мультикастинг-туннелей требует принципиально новых решений задачи маршрутизации, первой попыткой разрешить эту проблему был протокол DVMRP. Следует иметь в виду, что DVMRP может решить лишь часть задачи, хотя бы потому, что это внутренний протокол. Главной особенностью мультикастинг-маршрутизации является то, что нужно проложить маршруты от источника к совокупности адресатов, от которых пришли запросы участия в процессе. Режим мультикастинга поддерживается не всеми маршрутизаторами Интернет. Возможны конфликты при решении задачи маршрутизации, когда транзитный маршрутизатор не имеет "своих" участников группы (а должен выделить заметный ресурс каналов для удовлетворения внешних запросов). |
|
Previous:
4.4.9 Протокол IGMP
UP:
4.4 Интернет
|
