Рис. 1. Адрес узла назначения уровня 2

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

Коммутатор уровня 2 просматривает таблицу коммутации (см. табл. 1) для определения того, к какому его порту подключен узел назначения, указанный в текущем фрейме.

Табл. 1. Таблица коммутации уровня 2

MAC-адрес узла назначения

Порт назначения

00-00-0с-06-41-7с

3/3

00-00-0с-02-b9-01

3/3

00-80-24-07-8c-60

3/2

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

Когда посланный фрейм содержит в поле адреса назначения широковещательный или многоцелевой адрес, то коммутатор уровня 2 распространяет его по всем интерфейсам. На рис. 2 показан процесс, происходящий тогда, когда коммутатор уровня 2 получает трафик multicast.

Рис. 2. Процесс обработки фреймов Broadcast и Multicast коммутатором уровня 2

Технологии Multicast используются в современных сетях в разных целях. Такие протоколы, как, например EIGRP (Enhanced Interior Gateway Routing Protocol) и OSPF (Open Shortest Path First), используют пакеты multicast для рассылки маршрутных обновлений между соседними маршрутизаторами. Более важной сферой применения технологий Multicast является организация групповой обработки данных прикладными программами. Одним из наилучших примеров такой обработки является использование рассылки данных мультимедиа, когда видео и аудиоданные распространяются по мере подключения пользователей к группам рассылки.

Для применения технологий Multicast необходимо понимание трех основных типов пакетов, служащих для передачи данных по сети: Unicast (одноцелевые), Multicast (групповые) и Broadcast (широковещательные) пакеты.

Рис. 3. Передача пакетов Unicast

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

Пакеты Broadcast

Рис. 4. Передача пакетов Broadcast

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

Пакеты Multicast

Рис. 5. Передача пакетов Multicast

При таком дизайне приложения рассылают по одной копии каждого пакета на групповой адрес, причем именно клиент определяет, надо ли ему обрабатывать пакеты с таким адресом. Использование технологий Multicast обеспечивает возможность контролирования объема передаваемого трафика, а также ограничивать объем вычислений, производимых активным сетевым оборудованием и конечными узлами сети, что позволяет исключить избыточность трафика (см. рис.5).

Для понимания преимуществ использования технологий Multicast рассмотрим работу видео-сервера, использующего данные в формате MPEG. Воспроизведение одного видеопотока MPEG требует полосы пропускания примерно в 1,5 Мбит/с. В условиях сети Unicast видео-сервер рассылает трафик со скоростью, определяемой по формуле 1,5 Мбит/с * n, где n – это общее число клиентов рассылки. Таким образом получаем, что при использовании сети с пропускной способностью 10 Мбит/с рассылка 6 или 7 потоков одновременно полностью исчерпывает пропускную способность сети. При использовании же технологий Multicast серверу достаточно рассылать всего 1 копию видеопотока на 1 адрес Multicast, причем независимо от числа активных клиентов, принимающих этот поток. Получается, что при использовании Multicast серверу достаточно свободной полосы пропускания в 1,5 Мбит/с, что обеспечивает возможность утилизации оставшейся пропускной способности для иных целей.

Технологии передачи Multicast могут применяться как на уровне 2, так и на уровне 3. Например, сети Ethernet и FDDI (Fiber Distributed Data Interface) поддерживают все 3 типа пакетов. Индивидуальный компьютер может получать пакеты на адрес Unicast, несколько адресов Multicast и на адрес Broadcast. Сети Token Ring также поддерживают концепции Multicast, правда, они используют для этого несколько иные механизмы. Сети Token Ring имеют функциональные адреса, которые можно использовать для идентификации групп рассылки.

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

При внедрении приложения Multicast в кампусную сеть, содержащую несколько типов сред и систем передачи данных, таких как Ethernet, Token Ring, FDDI, ATM (Asynchronous Transfer Mode), Frame Relay, SMDS (Switched Multimegabit Data Service) и других сетевых технологий, наилучшим вариантом применения Multicast является его внедрение на уровне 3, если, конечно, трафик такого типа не предназначен только для одного сетевого сегмента.

Для поддержки Multicast на сетевом уровне необходимо определить несколько параметров:

• Адресация – Необходимо иметь адрес сетевого уровня, отвечающий за соединения между серверами и группами рассылки, причем группы рассылки могут состоять как из одного, так и из большого числа пользователей. Кроме того, необходимо обеспечить механизм установления соответствия между этим адресом и адресами уровня 2, которые используются при работе Multicast на канальном уровне.
• Динамическая регистрация – Необходимо обеспечить механизм регистрации компьютера, подключенного к сети, в определенных группах рассылки. Без такого механизма невозможно определить, по каким именно подсетям необходимо передавать трафик для каждой группы рассылки.
• Маршрутизация Multicast – Сеть должна обеспечивать построение деревьев распределения пакетов, которые позволят источникам рассылки отправлять пакеты всем узлам-приемникам. Основной задачей деревьев распределения пакетов является обеспечение нахождения каждого пакета в определенной подсети только один раз (например, если внутри офисной сети имеется несколько получателей пакетов Multicast, то на всю офисную сеть должна приходить только одна копия каждого пакета).

Организация IETF (Internet Engineering Task Force) разработала ряд стандартов, соответствующих пунктам, перечисленным в предыдущем разделе.

• Адресация – Адресное пространство IP разделяется на четыре части: Class A, Class B, Class C и Class D. Для трафика Unicast отводятся Class А, В и С. Class D резервируется для трафика Multicast. Адреса из диапазона Class D распределяются динамически.
• Динамическая регистрация – Документ RFC-1112 определяет протокол IGMP (Internet Group Management Protocol), который обеспечивает возможность конечного узла сети информировать всю сеть о подключении этого узла к определенной группе рассылки.
• Маршрутизация Multicast – Для обеспечения маршрутизации Multicast был разработан целый ряд стандартов:

• RFC-1075, определяющий протокол DVMPR (Distance Vector Multicast Routing Protocol)
• RFC-1584, определяющий протокол MOSPF (Multicast OSPF) – расширение протокола OSPF (Open Shortest Path First), поддерживающее IP Multicast
• Два предварительных описания стандартов, представленных Cisco Systems, определяющих протокол PIM (Protocol Independent Multicast) – протокол, который может использоваться совместно с любым стандартным протоколом маршрутизации IP Unicast.

На рис. 6 показан формат адреса IP Multicast Class D.

Рис. 6. Формат адреса Class D

В отличие от адресов Class A, B и С младшие 28 бит адреса Class D не имеют определенной структуры. Адрес группы Multicast является двоичной комбинацией значения 1110 в старших 4 битах адреса и идентификатора группы, обычно обозначаемого в десятичной форме в диапазоне от 224.0.0.0 до 239.255.255.255.

В связи с тем, что значение старшего октета начинается с двоичной комбинации 1110, то значение 224 является базовым адресом.
Конечные узлы, обеспечивающие прием пакетов, имеющих определенный адрес IP Multicast, называются группой узлов. Группа узлов может охватывать несколько подсетей. Участие узлов в группе определяется динамически – узлы могут подключаться к группе и отключаться от нее. Более подробно о процессе регистрации в сети IP Multicast рассказывается в разделе, посвященном протоколу IGMP.

Некоторые адреса групп соответствуют определенному типу узлов. Это определено в соответствующем документе IANA (Internet Assigned Numbers Authority). Эти группы называются постоянными группами узлов, аналогично тому, как распределяются номера портов TCP и UDP. В таблице 2 показаны некоторые такие группы.

Табл. 2. Зарегистрированные адреса Class D

Адрес Class D

Назначение

224.0.0.1

Все узлы в данной подсети

224.0.0.2

Все маршрутизаторы в данной подсети

224.0.0.4

Все маршрутизаторы DVMRP

224.0.0.5

Все маршрутизаторы MOSPF

224.0.0.9

Протокол RIPv2 (Routing Information Protocol Version 2)

224.0.1.1

Протокол NTP (Network Time Protocol)

224.0.1.2

SGI Dogfight

224.0.1.7

Audio news

224.0.1.11

IETF audio

224.0.1.12

IETF video

Кроме резервирования адресов Class D IANA владеет блоком адресов Ethernet, начинающихся с шестнадцатеричной комбинации 00:00:5e. Эта комбинация представляет собой старшие 24 бита адреса Ethernet, что означает, что весь блок адресов включает в себя диапазон с 00:00:5e:00:00:00 по 00:00:5e:ff:ff:ff. Половина адресов этого блока резервируется для передачи пакетов Multicast. Первый байт каждого адреса Ethernet должен содержать комбинацию 01, которая и определяет данный пакет, как пакет Multicast. Таким образом, для передачи IP Multicast используются адреса в диапазоне от 01:00:5e:00:00:00 до 01:00:5e:7f:ff:ff.

Такое резервирование адресов позволяет использовать 23 бита адреса Ethernet для идентификации группы рассылки IP Multicast. Таким образом, младшие 23 бита адреса IP Multicast полностью соответствуют 23 битам адреса Ethernet (см. рис. 7).

Старшие 5 бит адреса Multicast игнорируются и не являются уникальными. Таким образом, каждому адресу Ethernet можно назначить до 23 идентификаторов групп Multicast.

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

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

При получении дейтаграммы Multicast конечным узлом сети узел должен выполнить все необходимые операции по обработке пакета, предписанные данной группе рассылки. Этот сценарий несколько отличается от обработки UDP, так как в последнем случае входящая дейтаграмма UDP обрабатывается одной операцией. В случае же с Multicast возможно выполнение нескольких операций на данном конечном узле в составе группы рассылки.

Сложности начинаются при применении технологий Multicast за пределами одно локальной сети. При использовании уровня 2 MAC-адреса назначения Multicast обрабатываются так же, как и адреса Broadcast, т.е. пакеты распространяются по всем портам сетевых устройств уровня 2. Все коммутаторы, получая на один из портов поток пакетов Multicast, распространяют его по всем своим интерфейсам, и т.д. Результатом такой обработки является то, что в большинстве случаев пакеты попадают в такие подсети и сетевые сегменты, в которых нет ни одного участника группы рассылки. К счастью, маршрутизаторы на уровне 3 могут разрешить эту проблему, блокируя передачу любых фреймов Broadcast и Multicast уровня 2. Однако, до тех пор, пока маршрутизаторы не будут соответствующим образом передавать пакеты Multicast, для передачи (или не передачи) таких пакетов придется пользоваться отдельным протоколом. Эти функции выполняются протоколом IGMP, который сообщает маршрутизатору о том, что, например, некоторый узел на некоторой подсети, подключенной к данному маршрутизатору, “хочет” присоединиться к данной группе рассылки.

Как и любая другая часть уровня IP, протокол IGMP использует для передачи данных дейтаграммы протокола IP. В отличие от других протоколов этого семейства, IGMP имеет фиксированный размер поля данных внутри дейтаграммы IP (см. рис. 8).

Рис. 8. Дейтаграмма IP с сообщением
протокола IGMP

Сообщения протокола IGMP обозначаются в поле идентификатора протокола дейтаграммы IP значением 2. Формат сообщения IGMP внутри дейтаграммы IP показан на рис. 9.

Протокол IGMP реализован в двух версиях – Type 1 и Type 2. Сообщения Type 1 являются запросами, рассылаемыми маршрутизаторами Multicast, а сообщения Type 2 являются ответами на эти запросы,посылаемыми конечными узлами сети. Групповой адрес – это ничто иное, как адрес IP Class D. При запросах групповой адрес имеет значение 0, а при ответах это поле содержит адрес группы рассылки.

Рис. 9. Формат сообщения IGMP

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

1. Конечный узел сети посылает пакет IGMP типа report для обеспечения запуска процесса подключения к группе рассылки. Если на данном конечном узле выполняются сразу несколько процессов подключения к одной и той же группе, то посылается только один пакет IGMP. Причем этот пакет посылается только на тот интерфейс, который имеет соединение с сервером рассылки.
2. Узел не посылает никаких дополнительных пакетов при отключении от группы рассылки, даже если последним покидает группу. Каждый конечный узел “знает” о том, что в данной группе нет ни одного участника, поэтому при получении следующего запроса ему не за чем информировать группу.
3. Маршрутизатор Multicast через определенные временные интервалы посылает в сеть запросы IGMP. Эти запросы позволяют определить текущее состояние групп рассылки. Маршрутизатор должен отправить по одному запросу на каждый интерфейс. Адрес группы в запросе равен 0 до тех пор, пока маршрутизатор не обнаружит хотя бы одного работающего клиента из любой активной группы рассылки.
4. Узел посылает ответный пакет IGMP для каждой группы рассылки до тех пор, пока имеется хотя бы один клиент данной группы.

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

Рис. 10. Запросы и ответы IGMP

пределах одной подсети. Дейтаграммы с большим значением TTL могут обрабатываться и передаваться маршрутизаторами Multicast.
Увеличивая значение TTL, приложения могут расширять круг поиска определенных серверов. Первая дейтаграмма Multicast в потоке всегда имеет значение TTL равное 1. Если на эту дейтаграмму не приходит ответа от сервера, то посылается следующая дейтаграмма с полем TTL равным 2. Затем 3 и т.д. Таким образом, приложение обнаруживает далеко стоящий сервер, причем попутно определяется количество промежуточных маршрутизаторов на пути от клиента до сервера (Number of Hops).

Специальный диапазон адресов от 224.0.0.0 до 224.0.0.255 предназначен для тех приложений, трафик которых никогда не выходит за пределы одного промежуточного маршрутизатора. Маршрутизатор Multicast никогда не обрабатывает пакеты с такими адресами, несмотря на значение поля TTL.

Маршрутизация Multicast

Одним из необходимых требований для передачи трафика Multicast через маршрутизируемые сети является наличие маршрутного протокола Multicast. В настоящее время известны 3 таких протокола – DVMRP, MOSPF и PIM. Назначение каждого из них заключается в нахождении внутри сети маршрута для следования трафика Multicast и обеспечение доставки этого трафика каждому заинтересованному участнику сети.

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

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

Для определения того, какой интерфейс является источником потока данных Multicast, и предотвращения распространения трафика в обратном направлении, протокол DVMRP использует свой собственный маршрутный протокол типа Unicast. Этот протокол в достаточно большой степени похож на протокол RIP; он основывается на числе промежуточных узлов при определении метрики маршрута. В результате трафик Multicast не всегда следует тем же маршрутом, что и трафик Unicast.

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

Протокол DVMRP применяется для организации MBONE (Multicast backbone across the public Internet), обеспечивая реализацию туннелей между устройствами, работающими с этим протоколом. Такие вещи, как MBONE, повсеместно используются для обеспечения настольной конференц-связи между компьютерами и их группами, установленными на значительном расстоянии друг от друга и соединенными публичными каналами связи. В недалеком будущем планируется отход MBONE от применения DVMRP; вместо него планируется использование протокола PIM в связи с тем, что PIM имеет лучшие параметры эффективности. Преимуществам протокола PIM перед DVMRP посвящена часть раздела с описанием PIM.

Протокол MOSPF(Multicast Extensions to OSPF, RFC-1584)

Протокол MOSPF определен, как расширение маршрутного протокола Unicast OSPF. В основе работы протокола OSPF находится концепция того, что каждый маршрутизатор сети “знает” обо всех имеющихся сетевых соединениях. Каждый маршрутизатор OSPF вычисляет маршруты от себя до всех возможных узлов и подсетей.

Работа протокола MOSPF основана на том, что к маршрутным обновлениям OSPF добавляется информация Multicast. Маршрутизатор MOSPF в процессе работы накапливает информацию о группах Multicast, которые в настоящий момент активны в сети.

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

Естественно, что протокол MOSPF работает только в тех сетях, которые используют протокол OSPF.

Протокол MOSPF является наилучшим решением для таких сетевых систем, в которых имеется небольшое число пар “источник – группа рассылки”, активных в данных момент времени. Менее хорошо этот протокол будет работать в сетевых системах с большим количеством активных источников или в системах, имеющих нестабильные линии связи.

В отличие от MOSPF, работающего только с протоколом OSPF, протокол PIM работает с любым из известных маршрутных протоколов. Также, в отличие от DVMRP, имеющего по определению проблемы с масштабируемостью, протокол PIM предоставляет два различных типа схем распределения многоадресного трафика, обеспечивающих масштабирование маршрутизации Multicast: режимы Dense Mode и Sparse Mode.

Режим Dense Mode PIM чаще всего используется в следующих случаях:

• Отправители и получатели информации находятся в непосредственной близости друг от друга

• Имеется небольшое количество отправителей и большое количество получателей рассылки

• Имеется большой объем трафика Multicast

• Плотность потоков данных Multicast находится постоянно примерно на одном уровне.

Режим Dense Mode использует, так же как и DVMRP, механизм Reverse Path Forwarding. Основным отличием между DVMRP и Dense Mode PIM является тот факт, что PIM работает независимо от того, какой маршрутный протокол Unicast используется на данном соединении. Другими словами, протокол PIM не требует наличия в сети какого-либо определенного протокола Unicast.

Рис. 11. Работа протокола Dense Mode PIM

В режиме Dense Mode протокол PIM распространяет запросы и ответы на подключение или отключение от групп рассылки сразу обо всей подсети, основываясь на информации о составе групп Multicast. В частности, при использовании телевизионного вещания в условиях локальной сети этот режим достаточно эффективен в связи с тем, что он обеспечивает быстрое распространение информации о подключениях и отключениях клиентов от групп рассылки во всех подсетях. Распространение информации о подсетях также эффективно благодаря тому, что требуется небольшое количество трафика для рассылки такого объема информации. Программное обеспечение Cisco IOS (Cisco Internetwork Operating System) обеспечивает поддержку протокола Dense Mode PIM.

Рис. 12. Работа протокола Sparse Mode PIM

Режим Sparse Mode PIM обычно применяется в следующих случаях:

• При наличии небольшого количества получателей рассылки в каждой группе

• Источники и получатели рассылки соединены между собой каналами WAN

• Трафик характеризуется непостоянной плотностью

На рис. 12 показано функционирование Sparse Mode PIM. Этот режим оптимизирован для таких ситуаций, при которых большое количество многонаправленных потоков данных и каждый поток Multicast связаны с небольшим количеством локальных сетевых сегментов внутри общей сети. При таком типе групп рассылки механизм Reverse Path Forwarding неэффективно использует полосу пропускания сети. Механизм, используемый Sparse Mode PIM, называется Rendezvous Point (точка встречи). Когда источник отправляет данные, то сперва он отправляет их на точку встречи, и если получатель подключается к группе рассылки, то ему необходимо зарегистрироваться в этой точке. При передаче трафика по маршруту “Источник – точка встречи – получатель” маршрутизаторы автоматически оптимизируют путь следования трафика, исключая тем самым лишние промежуточные узлы. Режим Sparse Mode PIM предполагает, что ни один узел не начинает рассылку пакетов Multicast без предварительного запроса клиента. Программное обеспечение Cisco IOS осуществляет поддержку этого режима протокола PIM.

Информация о том, как конфигурировать маршрутизацию IP Multicast на устройствах Cisco Systems содержится на CD-ROM Cisco Connection Documentation.

Очевидно, что благодаря адресной схеме Class D, протоколам IGMP и PIM есть возможность создания хорошего механизма распределения трафика IP Multicast в маршрутизируемых сетях на основе оборудования Cisco Systems, однако, этот механизм основывается на распределенных адресах уровня 3, что создает определенные проблемы при использовании коммутации уровня 2. Дело в том, что в коммутационных таблицах коммутаторов для этого типа трафика не создается никаких записей, что приводит к тому, что поток Multicast плотностью 1,5 Мбит/с просто передается на все порты ком