От одного - ко многим

Протокол IP предусматривает как единичную, так и групповую адресацию. Мы рассмотрим особенности последней, а также алгоритмы построения деревьев доставки группового трафика через распределенную сеть.

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

Всю совокупность требований к многоадресной передаче данных позволяют реализовывать следующие специализированные протоколы: Internet Group Management Protocol (IGMP), Distance Vector Multicast Routing Protocol (DVMRP), Multicast OSPF (MOSPF) и Protocol-Independent Multicast (PIM). Протокол IGMP - это протокол управления группой. Его применение является обязательным при многоадресной передаче данных. Остальные протоколы (DVMRP, MOSPF, PIM) - это протоколы многоадресной маршрутизации, они взаимозаменяемы и применяются в зависимости от конкретной ситуации. При этом следует отметить, что все перечисленные протоколы работают только с протоколом передачи данных IP.

ПОПАДАЕМ ПО АДРЕСУ

Протокол IP поддерживает три способа адресации своих пакетов: единичную (unicast), широковещательную (broadcast) и групповую (multicast).

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

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

При групповой адресации приложения посылают всего один пакет, причем он будет доставлен только группе хостов, заинтересованных в его получении. При этом (что очень важно при работе в распределенных сетях) не генерируется избыточный трафик при передаче одной и той же информации группе хостов. На Рисунке 1 приведены примеры использования единичной, широковещательной и групповой адресации при доставке пакета.

Основным различием между пакетами с групповым и единичным адресом является содержимое поля "адрес получателя". В заголовке IP-пакета вместо IP-адресов классов A, B, C содержится адрес класса D, т. е. групповой адрес.

Групповой адрес присваивается некоторому множеству хостов-получателей, иными словами, группе. Хост-отправитель записывает данный групповой адрес как адрес получателя в заголовок IP-пакета. В соответствии с этим адресом пакет будет доставлен всем членам группы. Первые четыре бита адреса класса D равны '1110'. Остальную часть адреса занимает идентификатор группы, состоящий из 28 бит (Рисунок 2).

В точечно-десятичной записи групповой адрес задается в диапазоне IP-адресов от 224.0.0.0 до 239.255.255.255. На Рисунке 3 показана схема разделения адресного пространства для адресов класса D.

Как видно из рисунка, первые 256 адресов являются зарезервированными. В частности, этот диапазон отведен протоколам маршрутизации и другим низкоуровневым протоколам. В Таблице 1 приведены наиболее известные IP-адреса класса D, зарезервированные для специальных целей.

ТАБЛИЦА 1 - ОБЩЕИЗВЕСТНЫЕ ЗАРЕЗЕРВИРОВАННЫЕ АДРЕСА КЛАССА D

Выше этого диапазона находится большая группа адресов, выделенных для приложений, работающих в сети Internet. Самый верхний диапазон адресов (примерно 16 миллионов) может использоваться для локально-административных целей и для приложений, которые не ориентированы на работу в Internet. Централизованным управлением и регистрацией групповых адресов класса D занимается специальная организация IANA (Internet Assigned Numbers Authority).

Групповая адресация может быть реализована на двух уровнях модели OSI - канальном (Data-Link Layer) и сетевом (Network Layer). Протоколы передачи канального уровня, например такие, как Ethernet и FDDI, могут поддерживать единичную, широковещательную и групповую адресацию. Групповая адресация на канальном уровне позволяет получить дополнительные преимущества при доставке IP-пакетов с групповыми адресами, в случае если она поддерживается сетевой платой на аппаратном уровне.

Для поддержки этой функции организация IANA владеет блоком групповых Ethernet-адресов, начиная с 01-00-5E (шестнадцатиричное представление). На Рисунке 4 приведена схема трансляции группового IP-адреса в этот резервный блок групповых Ethernet-адресов. Принцип трансляции достаточно прост: младшие 23 бита идентификатора IP-группы копируются в младшие 23 бита Ethernet-адреса. При этом необходимо учитывать, что схема позволяет ассоциировать до 32 различных IP-групп с одним и тем же Ethernet-адресом, так как следующие 5 бит идентификатора IP-группы игнорируются.

Если отправитель и получатель являются членами одной физической сети, процесс передачи и приема групповых кадров на канальном уровне данных достаточно прост. Отправитель указывает IP-адрес группы получателей, а сетевая плата выполняет процедуру трансляции этого адреса в соответствующий групповой Ethernet-адрес и посылает кадр. Если отправитель и получатель находятся в разных подсетях, которые, однако, связаны маршрутизаторами, то доставка пакетов затруднена. В этом случае маршрутизаторы должны поддерживать один из групповых протоколов маршрутизации (DVMRP, MOSPF, PIM). Этот протокол построит дерево доставки и передаст групповой трафик. Кроме того, каждый маршрутизатор должен поддерживать протокол управления группой (IGMP) для определения наличия членов группы в непосредственно подключенных подсетях (Рисунок 5).

КТО "ЖИВЕТ" В НАШЕЙ ГРУППЕ?

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

Основываясь на информации, полученной с помощью протокола IGMP, маршрутизаторы могут определять, в какие подключенные подсети необходимо передавать групповой трафик. Маршрутизатор использует эту информацию совместно с протоколами многоадресной маршрутизации для передачи такого типа трафика через распределенную сеть или сеть Internet.

Протокол IGMP имеет несколько версий. Его первая и наиболее распространенная версия описана в документе RFC-1112. Маршрутизатор периодически рассылает сообщения Host Membership Query (HMQ) для определения хостов, расположенных в подключенных к нему подсетях, и определения их членства в группах. Адрес этих сообщений задается равным 224.0.0.1, то есть они адресуются всем хостам в подсети, а поле TTL (Time to Live) IP-пакета - задается равным единице. Это означает, что данное сообщение не будет обрабатываться другими маршрутизаторами в этой подсети. Напомним, что маршрутизаторы, перед тем как передавать пакет дальше, уменьшают поле TTL на единицу, и если при этом его значение оказывается равным нулю, то сообщение удаляется из обращения.

После того как хост получает сообщение HMQ, он отправляет сообщение Host Membership Report (HMR) для каждой группы, членом которой он является. Для того чтобы этих сообщений не оказалось чересчур много, каждый активный хост выжидает некоторое время перед отправкой очередного сообщения. Если за это время хост обнаружит сообщение HMR от другого члена его группы, то останется в этом режиме еще на некоторое время. Такая схема гарантирует, что все сообщения будут доставлены в определенный интервал времени, а порождаемый ими трафик окажется оптимальным.

Протокол IGMP использует сообщение фиксированной длины восемь байт внутри IP-пакета (Рисунок 6).

На Рисунке 7 приведен формат самого сообщения IGMP. Поле "Тип IGMP" может быть равно либо 1, что означает запрос, посылаемый маршрутизатором (HMQ), либо 2 - отклик на этот запрос от хоста (HMR). Значение тридцатидвухбитного поля "Групповой IP-адрес" задается равным нулю при сообщении HMQ и адресу группы при сообщении HMR.

Рисунок 8 иллюстрирует значения полей сообщений протокола IGMP.

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

В том случае, если маршрутизатор не получил сообщение HMR после ряда HMQ-запросов, он заключает, что члены группы больше не представлены в подключенной подсети, и группа удаляется из его списка. Когда хост первый раз становится членом определенной группы, он немедленно посылает сообщение HMR, не ожидая опроса маршрутизатора. Это гарантирует, что хост будет получать пакеты с групповым адресом даже в том случае, если он является первым и единственным членом группы.

Более поздние реализации протокола IGMP (версии 2 и выше) значительно расширяют возможности первой версии и обратно совместимы с ней. В частности, во второй версии IGMP вводится новая процедура выбора доминирующего маршрутизатора для каждой подсети: маршрутизатор с наименьшим IP-адресом назначается доминирующим. В первой версии он определялся с помощью протоколов многоадресной маршрутизации, что могло служить причиной возникновения нештатной ситуации, так как различные протоколы многоадресной маршрутизации используют неодинаковые методы выбора. Например, несколько маршрутизаторов могли быть назначены доминирующими.

ВЫРАЩИВАНИЕ ДЕРЕВЬЕВ

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

Дерево доставки - это, по существу, не что иное, как некоторое количество путей, выбираемых таким образом, чтобы пакеты с групповыми адресами доставлялись только тем хостам, которые хотят их получать. Алгоритмов формирования деревьев доставки существует достаточно много. Среди них можно отметить Flooding, Spanning Tree, Reverse Path Broadcasting, Truncated Reverse Path Broadcasting, Reverse Path Multicasting, Core-Based Tree. Некоторые из этих алгоритмов реализованы в наиболее распространенных протоколах многоадресной маршрутизации, таких как DVMRP, MOSPF, PIM.

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

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

Более эффективным решением служит механизм алгоритма остового дерева (Spanning Tree). Результатом работы этого алгоритма является древообразная структура, в которой между двумя любыми маршрутизаторами в распределенной сети есть только один активный путь. На Рисунке 9 показан результат работы алгоритма с корнем остового дерева в точке R.

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

Еще более действенным решением, чем формирование одного остового дерева для всей распределенной сети, будет создание остового дерева для каждого отправителя в группе, т. е. формирование деревьев доставки от источника (Source-Rooted Trees, SRT). Корень такого дерева находится в подсети, где располагаются хосты-отправители пакетов с групповыми адресами. Эти деревья создаются для каждой активной пары (отправитель, группа-получатель).

Основным алгоритмом для построения дерева доставки от источника является алгоритм вещания по обратному пути Reverse Path Broadcasting (RPB). Для каждой пары (отправитель, группа-получатель) при получении пакета по каналу связи, оцененному маршрутизатором как самый короткий путь назад к отправителю, маршрутизатор передает пакет на все свои интерфейсы, за исключением принявшего. Интерфейс, через который маршрутизатор ожидает получить пакет с групповым адресом от конкретного отправителя, обозначается как родительский. Интерфейсы, через которые пакеты передаются дальше, - как порожденные (Рисунок 10). Пакет, поступивший на порожденные интерфейсы, удаляется из обращения.

Рисунок 11 иллюстрирует работу алгоритма RPB. Маршрутизатор А получает пакет с групповым адресом от хоста-отправителя и передает его в каналы связи 1 и 2, т. е. через свои порожденные интерфейсы. Маршрутизатор Б получает этот пакет из канала 1 на свой интерфейс, который является родительским для этой пары (отправитель, группа-получатель), и передает его дальше через каналы 4 и 5. В случае передачи пакета через канал связи 3 он будет удален из обращения маршрутизатором В, так как пакет будет доставлен ему не на родительский интерфейс для этой пары.

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

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

Для разрешения этой проблемы был разработан алгоритм Truncated Reverse Path Broadcasting (TRPB). Алгоритм использует информацию, собранную с помощью протокола IGMP. При этом маршрутизаторы определяют наличие членов группы в каждой подключенной подсети и не передают пакеты в те подсети, в которых членов группы нет. Таким образом, ненужные ветви дерева доставки обрезаются.

Рисунок 12 иллюстрирует работу алгоритма TRPB. В этом случае маршрутизатор получает пакеты, адресованные группе Г1, на свой родительский интерфейс. Маршрутизатор будет передавать пакеты на порожденный интерфейс 1, так как в подключенной к нему подсети есть члены данной группы, а в порожденный интерфейс 3 пакеты передаваться не будут ввиду отсутствия там членов данной группы. На порожденный интерфейс 2 пакеты будут передаваться в том случае, если следующий маршрутизатор полагает, что данный канал связи является частью его родительского интерфейса для данной пары (отправитель, группа-получатель Г1).

Хотя этот алгоритм устраняет некоторые ограничения алгоритма RPB, часть проблем все же остается. В частности, устраняя ненужный трафик в подсети, он не принимает во внимание членство в группах при формировании дерева доставки. Этот недостаток алгоритмов RPB и TRPB устраняет алгоритм Reverse Path Multicasting (RPM) путем создания дерева доставки, охватывающего только те части распределенной сети, в состав которых входят члены группы-получателя.

Если маршрутизатор получает пакеты с групповыми адресами для пары (отправитель, группа-получатель), то первый пакет передается в соответствии с алгоритмом TRPB. При этом гарантируется, что все маршрутизаторы в распределенной сети его получат. Если члены группы-получателя присутствуют в подключенных к маршрутизаторам подсетях, то пакет будет доставлен на основании информации, полученной от протокола IGMP. Если же в подсетях нет членов группы-получателя, то маршрутизаторы передают специальные усекающие (prune) сообщения на свои родительские интерфейсы, информируя тем самым вышестоящие маршрутизаторы о том, что они не должны передавать групповой трафик для определенной пары (отправитель, группа-получатель) на свои порожденные интерфейсы, принявшие эти сообщения (Рисунок 13).

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

Рассмотрение данной темы мы продолжим в следующей статье.