Мультикастовые протоколы

Проблематизация

Мультикасты (multicast) появились не сразу. Сначала были лишь юникасты (unicast) и бродкасты (broadcast). Юникаст - это сообщение, которое посылается лишь одному узлу, бродкаст - сообщение, посылаемое всем узлам, находящимся внутри одной подсети. Причиной появления мультикастов стало желание рассылать некоторое сообщение группе узлов, а не всем, например, для автоматического обновления софта или просмотра потокового видео. Использование юникастов для этой цели слишком затратное по ресурсам. Бродкасты применять можно, но они все же замедляют работу сети, поскольку фрейм поднимается в стеке до уровня ip, прежде чем отбрасывается на машине, которая не желает получать групповое сообщение. Для решения этой проблемы и были применены мультикасты.

Реализация мультикастов

• Специальные mac адреса

  Во-первых, в ethernet был выделен диапазон специальных mac адресов от 00:00:5e:00:00:00 до 01:00:5e:7f:ff:ff, для того, чтобы фильтрация происходила в том числе и на уровне драйвера устройства, который знает, какие групповые рассылки ему надо принимать, а какие нет. Поскольку группа и mac адрес не отображаются друг в друга взаимнооднозначно, то некоторая фильтрация происходит по-прежнему на уровне ip, но ее объем значительно меньше.
  
  

  

• IP адреса класса D

  Целая сеть класса D (от 224.0.0.0 до 239.255.255.255) была выделена для групповых рассылок.
  
  

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

• Преобразование групповых адресов в адреса Ethernet

  На следующем рисунке показано преобразование IP адреса класса D в mac адрес.
  
  

  

Управление мультикастовыми группами

С целью управления группами был создан протокол IGMP (RFC 3376 (v3)). Этот протокол позволяет всем системам физической сети знать, какие хосты в настоящее время объединены в группы и к каким группам они принадлежат. Эта информация необходима для групповых маршрутизаторов, именно так они узнают, какие групповые датаграммы необходимо перенаправлять и на какие интерфейсы.

Инкапсуляция в IP.

Поля IGMP пакета.

1. Хост отправляет первый IGMP отчет, когда первый процесс вступает в группу. Если несколько процессов на данном хосте вступили в одну и ту же группу, отправляется только один отчет, в тот момент, когда процесс первый раз вступил в группу. Отчет посылается на тот же интерфейс, с которым процесс вступил в группу.
2. Хост не посылает отчет, когда процесс выходит из группы, даже когда последний процесс вышел из группы. Хост знает, что в этой группе больше нет членов, по-этому, когда он получает следующий запрос (следующий шаг), он не отправляет отчет.
3. Групповой маршрутизатор отправляет IGMP запрос с регулярными интервалами, чтобы выяснить, принадлежат ли процессы каких-либо хостов к каким-либо группам. Маршрутизатор посылает один запрос на каждый интерфейс. Групповой адрес в запросе установлен в 0, так как маршрутизатор ожидает приход одного отклика от хоста для каждой группы, к которой от хоста принадлежит один или несколько членов.
4. Хост отвечает на IGMP запрос посылкой одного IGMP отчета для каждой группы, которая содержит хотя бы один процесс.

Мультикастовые протоколы

• Проблематизация

  Имея возможность посылать мультикастовые протоколы, мы еще не можем, тем не менее, гарантировать доставку пакетов, поскольку групповой tcp просто не имеет смысла, а udp не имеет механизмов подтверждения доставки.
  В том случае, если канал посылки данных имеет уровень потерь в пределе 5-10%, то потоковое видео посылать вполне допустимо (будут небольшие искажения звука или картинки, что вполне приемлемо). Но такие потери недопустимы в случае обновление софта. Возникает необходимость разработки надежных мультикастовых протоколов (RMT - reliable multicast transport), которые при этом будут достаточно масштабируемыми.

• Общая классификация мультикастовых протоколов.

  • ACK-based protocols

    Acknowledgement-based - основанные на подтверждении. При получении соответствующего пакета, хост, его получивший, посылает рассылающему хосту подтверждение. Все преимущества мультикастов теряются. Очень плохая масштабируемость.

  • Tree-based ACK protocols

    Для уменьшения объема подтверждений, хосты, подписанные на рассылку, выстраиваются в древовидную структуру. Каждый хост-лист посылает подтверждение своему предку. Предок посылает подтверждение выше только в том случае, когда он получил подтверждение от всех своих сыновей.

  • NACK-based protocols

    Negative acknowledgement-base - основанные на уведомлении рассылающего хоста только о недошедших пакетах. Преимущества перед ACK-based:

    1. Рассылающему хосту теперь не нужно знать, сколько хостов в группе (не надо отслеживать, что ACK пришел от всех).
    2. Рассылающий хост может не отслеживать состояния подписанных на рассылку хостов.
    3. Объем обратного трафика значительно сокращается, если каналы связи достаточно надежны.

  • Asynchronous Layered Coding (ALC)

    Отличительная черта протоколов, входящих в эту группу, заключается в отсутствии обратного трафика. Это достигается благодаря использованию FEC (forward error correction). Как правило, в таких протоколах организованы несколько потоков, которые имеют разные скорости, для того, чтобы клиент мог выбрать оптимальную для себя скорость.

  • Router-assist protocols

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

Новые протоколы, разработанные RMT WG

Наиболее современными мультикастовыми протоколами являются протоколы, разработаные RMT WG (IETF Reliable Multicast Transport working group), в частности ALC и NORM.

• ALC (RFC 3450)

  Данный протокол был разработан специально для асинхронной рассылки (без ответов от клиентов), по причине асинхронности он абсолютно масштабируем, хотя не дает стопроцентной гарантии доставки.
  Основные его черты:
  

  1. Несмотря на то, что этот протокол специально создан для мультикастов, он поддерживает и множественные юникасты.
  2. Несколько потоков с разными скоростями, чтобы клиент мог выбирать наиболее приемлемую для себя скорость.
  3. Используется FEC (RFC 3452, RFC 3453), который по сути является кодированием Рида-Соломона.
  
  Для повышения надежности доставки одна и та же мультикастовая рассылка производится несколько раз подряд от начала до конца. Количество повторов зависит от конфигурации. Если канал достаточно зашумлен, то возможны коллизии.

• NORM (RFC 3940)

  Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol. Этот протокол использует NACK сообщения от клиентов. При получении NACK сообщения производится откат в посылке данных до пакета, который не был получен, с этого пакета возобновляется передача. Для уменьшения числа откатов используется FEC. Так же в этом протоколе реализован механизм контроля заполнения каналов (tcp-friendly congestion control), для выявления оптимальной скорости передачи данных.
  Благодаря введению обратной связи, данный протокол гарантирует доставку данных. Но из-за этого протокол менее масштабируем, чем ALC.

• Проблемы безопасности в ALC и NORM

  Возможны DOS атаки, это связано с тем, что можно посылать поддельные пакеты клиентам. Так же в NORM протоколе опасна возможность посылки рассылающему хосту поддельных NACK'ов.

Использованная литература

• "TCP/IP крупным планом" ("TCP/IP overview") Главы 12 и 13.
• Jan Grondahl "Reliable Multicast Transport - The new modular and highly scalable protocols".
• Joseph P. Macker "Reliable Multicast Transport and Integrated Erasure-Based Forward Error Correction".
• Joseph P. Macker, R. Brian Adamson "A tcp friendly, rate-based mechanism for NACK-oriented Reliable Multicast Congestion Control".
• RFC.