Система MBone

Санкт-Петербургский  национальный исследовательский университет

информационных технологий, механики и оптики

 

 

 

 

 

 

 

 

 

 

 

 

Доклад:

«Система MBone»

 

 

 

 

 

 

 

Выполнил:

студент группы 4131

Каталков Дмитрий Валерьевич

Проверил:

Разумовский Андрей Владимирович

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Санкт-Петербург

2012

Система MBone – аббревиатура от Multicast Backbone. Экспериментальный метод передачи цифровой видеоинформации по Интернету в реальном времени, виртуальная сеть, базирующаяся на мультикастинг-протоколах, которые были одобрены IETF летом 1992 года. В основу легли разработки, выполненные в компании «Ксерокс». Данный режим работы поддерживается не всеми маршрутизаторами. В общих чертах: сеть представляет собой систему Ethernet-сетей, объединенных друг с другом соединениями точка-точка, которые называются «туннелями». Конечными точками таких туннелей обычно являются машины класса рабочих станций, снабженные соответствующим программным обеспечением. Впервые мультикастинг-туннель был реализован в Стэнфордском университете в 1988 году.

 

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

 

Данная система представляет собой телевещание по Интернету. В отличие от видео по заказу, в котором упор делается на заказе и просмотре заранее сжатых и хранящихся на сервере видеофильмов, система используется для широковещательного распространения по Интернету передач, выходящих в прямом эфире, в цифровой форме. Эта система существует с 1992 года. Она использовалась для организации многочисленных научных телеконференций, особенно встреч проблемной группы проектирования Интернета, а также для освещения различных значимых событий науки, например, запусков космических челноков. Изобретателями данной системы являются Ван Якобсон, Стив Диринг и Стефан Каснер. Целью ее создание было – свести к минимуму объем данных, необходимых для многоточечных аудио-видеоконференций. Работа системы предполагала использование сети маршрутизаторов, которые могут поддерживать многоадресную рассылку, что обеспечило бы доступ к интерактивным ресурсам в режиме реального времени.

 

Технически система  представляет собой виртуальную  сеть поверх сети Интернет. Она состоит из соединенных туннелями островов, на которых возможна многоадресная рассылка. Сеть состоит из шести островов, от А до F, соединенных семью туннелями. Каждый остров поддерживает многоадресную рассылку на аппаратном уровне. По туннелям, соединяющим острова, рассылаются MBone – пакеты. Когда–нибудь в будущем, когда все маршрутизаторы будут напрямую поддерживать многоадресную рассылку, такая оверлейная структура станет ненужной, но пока что именно она обеспечивает работу системы.

 

На каждом острове находится один или несколько специальных многоадресных маршрутизаторов. Некоторые из них являются обычными маршрутизаторами, но большая часть представляет собой просто рабочие станции  UNIX, на которых на пользовательском уровне работает специальное программное обеспечение. Многоадресные маршрутизаторы логически соединены туннелями. MBone пакеты инкапсулируются по IP-адресу многоадресную маршрутизатора.

 

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

 

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

 

Таким образом, в любой  момент времени система состоит  из островов и туннелей, независимо от числа используемых в данный момент групповых адресов. Эта ситуация очень напоминает нормальную подсеть поэтому к ней применимы нормальные алгоритмы маршрутизации. Соответственно в системе MBone в системе изначально использовался алгоритм маршрутизации DVMRP  - протокол дистанционной маршрутизации сообщений с использованием векторной многоканальной трансляции, основанный на дистанционно-векторном алгоритме Беллмана-Форда. Например, остров С может быть связан  островом А либо через свой выбор на основании сообщаемых ему узлами значений своей удаленности от острова А и своей удаленности от других островов. Подобным образом каждый остров может определить лучший маршрут до всех остальных островов. Однако, как мы скоро увидим, эти маршруты необязательно используются именно таким образом.

 

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

 

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

 

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

 

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

 

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

 

Исследование в области  маршрутизации породили алгоритм PIM. Создано две версии алгоритма PIM, применяющихся в зависимости от плотности островов. Данный алгоритм используются стандартные таблицы одноадресной маршрутизации. Сам протокол PIM – протокол маршрутизации для IP-сетей, созданный для решения проблем групповой маршрутизации. PIM базируется на традиционных маршрутных протоколах, конкретно не связан ни с каким из них, им используются сформированные этими протоколами маршрутные таблицы. Существует два режима работы протокола - DM (для компактных групп) и SM (Protocol Independent Multicast-Sparse Mode (PIM-SM)). В режиме SM маршрутизаторы, имеющие членов мультикастинг-группы, посылают сообщения о присоединении к дереву рассылки в узлы, которые называются точками встречи (RP). Отправители используют RP для объявления о своем существовании, а получатели, чтобы узнать о новых отправителях. В качестве RP может использоваться любой маршрутизатор, поддерживающий протокол PIM.

Когда какой-то клиент хочет подключиться к некоторой группе, ближайший  к нему маршрутизатор посылает специальное  сообщение о включении в группу (PIM-joint) узлу, объявленному для данной группы точкой встречи (RP). Число RP в сети может быть произвольным. Узел RP пересылает сообщение о включении узлу-отправителю (или отправителям). Если маршрутизатор не имеет информации о RP, включается схема, работающая для компактных групп. При обработке сообщения о включении в группу промежуточные маршрутизаторы формируют часть дерева мультикастинг-маршрутов между RP и получателем. При отправке мультикастинг-пакета соответствующий маршрутизатор посылает узлу RP регистрационное сообщение (PIM-register), куда вкладывается информационный пакет. Если используется несколько RP, отправитель должен посылать пакеты всем RP. Получатель же должен быть подключен лишь к одному из RP. В случае, когда сообщение о включении достигнет отправителя раньше, чем RP, подключение осуществляется, минуя RP. Если необходимо оптимизировать дерево доставки пакетов, маршрутизаторы-получатели должны послать сообщение о включении самому отправителю. После этого дерево соединений видоизменяется, некоторыми узлами, если требуется, посылается сообщение об отключении.

 

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

 

Вариант алгоритма PIM для редко расположенных островов действует по-другому. Идея этого варианта заключается в том, чтобы не забивать Интернет излишней многоадресной рассылкой из-за небольшого числа пользователей, желающих устроить видеоконференцию с помощью IP-адресов класса D. В этом случае алгоритм создает так называемые точки встречи. Каждый источник посылает в эти точки свои пакеты. Любой сайт, желающий присоединиться к видеоконференции, просит установить туннель с точкой встречи. Таким образом, в этом варианте алгоритм PIM трафик переносится при помощи обычной одноадресной рассылки. Популярность данного варианта возрастает, и система MBone все чаще прибегает к его использованию.

 

По мере своего роста магистраль MBone сталкивалась со все возрастающим числом проблем. Общей причиной проблем была плоская (не иерархическая) виртуальная топология. Те же проблемы, которые были характерны для основанного классах механизма маршрутизации уникальных адресов, проявились и в MBone. При плоской топологии сетевые маршруты должны быть известны каждому маршрутизатору, а так как во время своего расцвета система включала почти 10 000 маршрутов, то объемы маршрутных данных приблизились к той черте, за которой маршрутизаторы становились практически неуправляемыми.

 

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

 

Опыт маршрутизации уникальных адресов говорил о необходимости  применения в групповом вещании  механизма агрегирования маршрутов  и создания на этой основе иерархической  топологии. Действительно, когда-то развитие обычной (использующей уникальные адреса) маршрутизации привело к разделению Интернета на автономные системы ( AS ), представляющие собой домены маршрутизации. Каждой автономной системой управляет одна организация, которая вольна организовывать маршрутизацию внутри этой системы так, как считает нужным, используя для этого протокол RIP, OSPF, IGRP или статические записи в таблицах маршрутизации. По умолчанию считается, что между автономными системами нет отношений доверия, поэтому маршрутная информация через границы AS передается под жестким надзором администраторов, держащих под контролем передачу через свой домен транзитной информации чужих доменов.

 

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

 

Задача создания протоколов междоменной  групповой маршрутизации была поставлена сетевым сообществом в 1997 году. На сегодняшний день существуют две группы решений. Первая группа — это так называемые тактические решения, которые могут работать уже сегодня, но не обладают достаточной масштабируемостью, чтобы стать основой развития Интернета на значительную перспективу. Поэтому продолжается работа по поиску долговременных стратегических решений, составляющих вторую группу. Стратегические предложения базируются как на стандартной модели группового вещания протокола IP, так и на более радикальных новых подходах.