Автор работы: Пользователь скрыл имя, 08 Июня 2014 в 15:22, дипломная работа
Основной целью группового вещания является создание эффективного механизма передачи данных по схеме "один-ко-многим" и "многие-ко-многим". Традиционные механизмы стека TCP/IP доставки пакетов мало пригодны для поддержки группового вещания. Например, использование уникальных адресов (unicast) приводит к необходимости установления многочисленных двухточечных соединений между отправителем и каждым из получателей. Другим способом передачи данных является широковещательная передача, когда станция направляет пакеты, используя широковещательные адреса (broadcast). Пакеты с такими адресами передаются всем конечным узлам указанной сети независимо от того, нужны ли они каждому из них. Во многих ситуациях такой способ передачи также оказывается неэффективным вследствие своей избыточности, которая ведет к чрезмерному росту трафика, особенно в крупных сетях.
В том же сообщении содержится список всех остальных соседних DVMRP-маршрутизаторов, о которых известно маршрутизатору. Если маршрутизатор не получает ни одного зондирующего сообщения (Probe), он полагает, что подсеть является всего лишь листовой сетью.
Маршрутная информация индивидуальной адресации рассылается между соседями при помощи специального пакета, называемого маршрутным отчетом (route report). В маршрутном отчете содержится список индивидуально адресуемых (исходящих) подсетей, их масок и метрики (стоимости доставки), связанной с каждой подсетью. Маршрут, определенный посредством маршрутных отчетов, должен быть обновлен в течении 140 с (2 * интервал между отчетами + 20), после чего он может быть заменен следующим наилучшим маршрутом для того же источника. Если нет обновления, значит, не существует альтернативных маршрутов - и по прошествии 200 с маршрут удаляется из таблицы маршрутов.
Маршрутный отчет рассылается каждые 60 с, и в течение этого интервала разрешается отсылать сколько угодно маршрутных отчетов. В любой момент этого промежутка времени допустимо разослать частичные обновления. Эти отчеты сообщают о переменах в сети, но содержат информацию только об изменившейся исходящей подсети, что уменьшает вероятность циклических изменений и других аварий при замене маршрутов до исходящей сети.
Получение маршрутного отчета - задача разносторонняя. Поступающая информация проверяется разными способами. Обрабатываются только маршрутные отчеты, принятые от известного соседа, а все остальные отбрасываются. В общем случае применяются два правила: если запись о маршруте новая и значение метрики меньше «бесконечности», то маршрут добавляется. Это простое правило. Второе правило сложнее. Оно показано в таблице.
Если запись о маршруте существует, необходимо провести следующие проверки:
Если новая метрика < «бесконечность» И новая метрика > существующая метрика
Если новая метрика < «бесконечность» И новая метрика < существующая метрика
Если новая метрика < «бесконечность» И новая метрика = существующая метрика
Если новая метрика = «бесконечность»И новый шлюз = существующий шлюз |
Если новый отчет поступил от того же самого соседа, то обновить запись; в противном случае выбросить ее. Обновить запись новым маршрутом и, если необходимо, обновить информацию о сообщающем соседе. Освежить маршрут и, если новый сосед имеет меньший IP-адрес, обновить запись. Маршрут теперь недостижим, Обновить запись |
Если новая метрика < «бесконечность» И новый шлюз не равен существующему
Если новая метрика находится между значением «бесконечности» для маршрута и удвоенным этим значением |
Проигнорировать
Coceд считает, что принимающий маршрутизатор является вышестоящим для указанного и маршрутизатор зависит от принимающего маршрутизатора на указанном маршруте. Если принимающий соседний маршрутизатор рассматривает маршрутизатор в качестве нижестоящего, то принимающий маршрутизатор помечает соседа, как зависящего от этого маршрута; в противном случае надо отбросить пакет, поскольку зависимый маршрутизатор нельзя считать вышестоящим |
Если значение метрики больше удвоенного значения «бесконечности» |
Проигнорировать |
Принимая групповую IP-датаграмму, маршрутизатор, на котором работает DVMRP, прежде всего ищет информацию об исходящей сети в своей таблице DVMRP-маршрутов индивидуальной адресации. Чтобы гарантировать, что все DVMRP-маршрутизаторы имеют логически корректную информацию о пути индивидуальной адресации назад до источника, таблица маршрутов индивидуальной адресации распространяется между всеми маршрутизаторами (данная функция является частью протокола). Это отдельная таблица маршрутов индивидуальной адресации для протокола DVMRP. На самом деле в групповой маршрутизации используются две таблицы: таблица маршрутов (routing table) и таблица перенаправления (forwarding table). В таблицу маршрутов DVMRP входит информация об исходящих подсетях (Source subnets) и исходящих шлюзах (From gateways). В ней содержится дерево связности с корнем в источнике всех кратчайших маршрутов до любой участвующей в процессе исходящей подсети сетевого пространства. Таблица перенаправления создается потому, что в таблице маршрутов нет информации о членском составе групп. Далее представлен пример таблицы маршрутов DVMRP:
Исходящая подсеть 150.1.0.0 150.2.0.0 |
Маска подсети 255.255.0.0 255.255.0.0 |
Исходящий шлюз 150.1.1.1 150.1.2.1 |
Метрика 5 3 |
Состояние Рабочее Рабочее |
TTL 400 350 |
В этой таблице:
Таблица перенаправления DVMRP:
Исходящая подсеть 150.1.0.0 |
Адресуемая группа 224.0.1.1 |
TTL
430 |
Вышестоящий порт 1 |
Нижестоящие порты 2, 3 |
Любой интерфейс, который представляет собой сеть-лист, или любой из нижестоящих маршрутизаторов будут включены в графу нижестоящих портов. Вышестоящий порт определяется по таблице маршрутов индивидуальной адресации следующим образом: если данный интерфейс обладает кратчайшим обратным маршрутом до исходящей подсети для данной группы, то он регистрируется как вышестоящий интерфейс для данного порта. Таблица перенаправления создается с тем, чтобы локальный маршрутизатор мог разобраться в дереве кратчайших путей доставки с корнем в источнике для каждой пары (источник, группа).
Чтобы построить таблицу маршрутов индивидуальной адресации, вышестоящий DVMRP-маршрутизатор полагается на информацию других нижестоящих маршрутизаторов. Информация, которая отсылается другим DVMRP-маршрутизаторам, называется маршрутным отчетом (route report). Поля метрики в маршрутном отчете - самые важные. Метрика позволяет построить не только таблицу исходящей подсети, показывающую исходящие подсети и их достижимость, но и таблицу перенаправления, которая сообщает маршрутизатору, какие нижестоящие маршрутизаторы зависят от данного вышестоящего маршрутизатора при перенаправлении им групповых датаграмм. Вышестоящие маршрутизаторы отправляют маршрутные отчеты своим нижестоящим соседям, указывая исходящие подсети и их метрики. Так же как и в RIP, метрика здесь - это совокупная стоимость доставки для всех предшествующих входящих интерфейсов. Маршрутные отчеты будут отосланы соседнему DVMRP-маршрутизатору. В них содержится список исходящих подсетей и метрики (1-31). Нижестоящий маршрутизатор вышлет обратно вышестоящему маршрутизатору копию отчета с метрикой, большей 32, чтобы информировать этот маршрутизатор о своей зависимости от него при получении групповых датаграмм от определенной исходящей подсети.
Значение «бесконечности» для DVMRP считается равным 32. Поэтому нижестоящий маршрутизатор добавит 32 к метрике во входящем отчете и вернет его вышестоящему маршрутизатору. Данный процесс основан на технике поглощения реверса (poison reverse). Вышестоящий маршрутизатор, получивший такое обновление и увидевший, что значение метрики для исходящей подсети лежит в диапазоне между «бесконечностью» и удвоенной «бесконечностью», добавит нижестоящий маршрутизатор в список зависимых маршрутизаторов для этого источника. Как уже отмечалось, значение «бесконечности» равно 32. Оно показывает, что исходящая сеть недостижима. Значение метрики может лежать в диапазоне от 1 до 63. Исходное значение метрики источника находится в пределах 1-31; 32 означает недостижимость, а интервал 33-63 - это метрики защитной реакции нижестоящего маршрутизатора, сообщающего своему вышестоящему маршрутизатору о том, что его необходимо добавить в таблицу для групповых датаграмм от данного источника.
Можно было бы воспользоваться существующей маршрутной таблицей, например RIP, но всё дело в том, что не все маршрутизаторы будут работать с DVMRP а групповые маршрутизаторы должны быть способны взаимодействовать с негрупповыми маршрутизаторами. Для обеспечения этого приходится строить туннели через негрупповые маршрутизаторы. При помощи туннелей явно задается эффективный маршрут для прохода групповой датаграммы. Не исключено, что туннель будет содержать один маршрут, а обычный индивидуально адресуемый пакет пойдет по другому маршруту. Так что таблица индивидуальной адресации маршрутизатора не обязательно совпадает с таблицей индивидуальной адресации маршрутизатора DVMRR. Именно поэтому мы используем информацию об индивидуальной адресации в DVMRP только для того, чтобы определить кратчайший обратный маршрут до исходящей подсети групповой датаграммы.
Большинство маршрутизаторов в Internet не работают с протоколом групповой адресации. Посредством туннелирования строится «островки» - автономные сети с групповой адресацией, и они взаимодействуют друг с другом через Internet посредством туннелирования.
DVMRP поддерживает возможность
Для инкапсуляции IP-датаграммы с применением инкапсуляции IP-B-IP, перед существующим заголовком IP-датаграммы вставляется еще один заголовок. Адреса отправителя и получателя во внешнем IP-заголовке описывают входную и выходную или конечные точки туннеля. Оригинальный IP-заголовок содержит исходный и целевой IP-адреса отправителя и конечного получателя датаграммы соответственно.
Protocol Independent Multicast, «протокольно-независимый» протокол групповой маршрутизации.
Протокол DVMRP предоставляет прекрасные механизмы для групповой адресации. Посредством последних версий IGMP и DVMRP можно динамически строить полнофункциональное дерево групповой адресации и использовать его для передачи звука, видео и обычных данных. Однако у DVMRP есть недостаток: он не обладает хорошими возможностями масштабирования. DVMRP - это протокол типа «вектор-расстояние», занимающийся обновлением групповой маршрутной информации. Он ретранслирует в широковещательном режиме первый полученный им от источника групповой пакет, а затем обрезает дерево в зависимости от информации, полученной с помощью обратной связи от других маршрутизаторов. DVMRP известен как плотнорежимный (dense mode) протокол групповой адресации и наиболее эффективен при плотном расположении клиентов в сети. Он не расширяется достаточно хорошо при работе в каналах глобальных сетей даже в том случае, когда узлы всего лишь разбросаны по клиентской сети. Такой механизм ретрансляции и обрезания вызывает, так же как и групповые маршрутные обновления, излишние накладные расходы в средах с малой шириной полосы пропускания. Кроме того, маршрутные таблицы DVMRP опираются на RIP-подобные обновления. Также DVMRP требует, чтобы маршрутизаторы хранили информацию о состоянии дерева. Сюда входят сведения о группе и источнике, необходимые для расчета дерева.
Если все члены адресуемой группы расположены в области с хорошей пропускной способностью (поддерживаемой высокоскоростными локальными сетями, а не низкоскоростными глобальными), то они должны поддерживаться плотнорежимным протоколом, таким как DVMRP, MOSPF или PIM-Dense Mode (DM). Здесь могут возникнуть ограничения: не удается включить в область охвата группы ни одного члена, который находится за областью видимости домена, без применения излишних ретрансляционных сообщений и сообщений об отрезании и, возможно, групповых маршрутных обновлений через канал, к которому принадлежит удаленная принимающая станция.
PIM предоставляет два варианта групповой маршрутизации: насыщенная маршрутизация (dense mode) н маршрутизация в разреженном режиме (sparse mode).
Насыщенный режим несложно понять, в работе он похож на DVMRP в том смысле, что использует RPM для построения деревьев групповой адресации с корнем в источнике. Тем не менее, в отличие от DVMRP, PIM не полагается на независимый протокол индивидуальной маршрутизации.
Групповой пакет, приходящий в интерфейс PIM-DM, перенаправляется во все интерфейсы, если только ветви не были специально отрезаны. В отличие от DVMRP, протокол PIM-DM будет продолжать отсылать групповые пакеты, пока не поступит специальное сообщение об отрезании. По этим сообщениям не строятся никакие таблицы. DVMRP с помощью таблицы маршрутов определяет, существуют ли нижестоящие маршрутизаторы, которым надо получать групповые датаграммы для конкретной группы. DVMRP, полагающийся на маршрутную таблицу, рассылаемую всем групповым маршрутизаторам, оказывается более избирательным при перенаправлении сообщений во время формирования дерева групповой адресации с корнем в источнике. Аргументом в пользу PIM здесь может выступать то обстоятельство, что простота и независимость протокола имеют более важное значение, чем дополнительные «накладные расходы», вызываемые дублированием пакетов, а построение таблицы индивидуальной маршрутизации фактически устраняет такое дублирование. PIM-DM рассматривает дублирование пакетов как альтернативу зависимости от протокола индивидуальной маршрутизации и, следовательно, избегает формирования еще одной маршрутной базы данных. PIM-DM полагает, что всем нижестоящим интерфейсам необходимо получать групповые датаграммы. На самом деле PIM разрабатывался для разреженных сетей с групповой адресацией, а режим повышенной плотности (DM) был добавлен для упрощения его функционирования. PIM-DM не использует концепции точек рандеву и периодические присоединения к группам (тем не менее сообщение о присоединении - join - все еще применяется).