Как известно, адресация любого IP-пакета имеет четыре составляющих — IP-адрес источника, IP-адрес получателя, порт источника и порт получателя. Надо иметь в виду, что в данном случае речь идет не о физическом порте, а о компьютерном процессе, которым этот пакет сформирован или которому адресован. Без указания порта назначения, компьютер, получивший пакет, просто не будет знать, каким образом его обрабатывать. А порт отправителя нужен для указания его в ответных пакетах в качестве порта получателя. Многие распространенные процессы имеют фиксированные номера портов. Например, протокол файловой передачи FTP имеет порт 20 для служебных команд и 21 для данных, а приложение ICQ — 5190. Для запуска нового процесса нужно назначить ему какой-то порт, который будет прописан в соответствующем приложении всех устройств, обменивающихся данными в рамках этого процесса.
Групповой (мультикастовый) адрес распознается по принадлежности к диапазону 224.0.0.0 — 239.255.255.255. В отличие от индивидуального адреса он индицирует не адресата, а передаваемый поток. И сам принцип прокладывания маршрута между источником и адресатом прямо противоположен тому, который используется при индивидуальной адресации. Пакет с индивидуальным адресом прокладывает свой путь от отправителя к получателю, передаваясь по сети от одного маршрутизатора к другому в соответствии с таблицами маршрутизации. А распространение мультикастового потока инициируется запросами со стороны получателей, и потому его маршруты прокладываются в противоположном направлении — от получателя к отправителю. Взаимодействие между источниками и получателями мультикастовых потоков управляется протоколом IGMP (Intenet Group Management Protocol). На сегодняшний день разработаны уже три версии протокола. Процедура подключения к мультикастовой группе выглядит следующим образом. Устройство, желающее подключиться к определенной мультикастовой группе, формирует IGMP-сообщение о подключении (membership report), содержащее адрес требуемой мультикастовой группы. Оно отправляется в сеть в направлении источника мультикастового потока. Когда запрос доходит до ближайшего маршрутизатора, уже получающего этот поток в ответ на более ранние запросы, этот маршрутизатор начинает ретранслировать его и на порт, с которого поступил новый запрос. В версии IGMP v.1 никаких активных сообщений о том, что устройство отключается от мультикастовой группы, не предусмотрено. Маршрутизатор, ближайший к источику мультикаста, периодически отправляет запрос (membership query) о том, есть ли еще в сети активные потребители этого мультикастового потока. Если подтверждений нет, то его вещание прекращается. Другими словами, запрошенный мультикастовый поток перестает передаваться на устройство, только когда от группы отключается последнее абонентское устройство. В некоторых ситуациях такая схема сильно загружает сеть лишним трафиком и легко может привести к перегрузке оконечного коммутатора. Минутного серфинга абонента по каналам достаточно, чтобы они «зависли» на коммутаторе, перегрузив его порты. Эта проблема в сильной мере решается при переходе на более поздние версии IGMP и одновременном использовании коммутаторов доступа с функцией IGMP Snooping. С появлением самой распространенной сегодня версии IGMP v.2 у абонентских устройств добавилась возможность отправлять сообщение об отключении от мультикастовой группы (leave group). Получая такое сообщение, источник сигнала с помощью запроса проверяет наличие активных членов группы, получающей данный конкретный поток, и если их не оказывается, то вещание потока прекращается. Это несколько ускоряет процесс остановки неактуальных мультикастовых потоков, но слабо помогает в борьбе с перегрузкой коммутатора, к которому подключен потребитель мультикастовых потоков. Причем если вспомнить, что обычный коммутатор — это устройство второго уровня, при коммутации оперирующее не IP-, а МАС-адресами, и что МАС-адрес устройства назначения в мультикастовом пакете невозможно указать по определению, то становится ясным, что коммутатор не в состоянии распознать, кому из подключенных к нему устройств адресован пакет. Поэтому он вынужден раздавать его на все выходные порты. То есть при «зависании» лишних мультикастовых потоков перегружаются все порты сразу. Для борьбы с этой проблемой в коммутаторы внедряют механизм, называемый IGMP Snooping. Он позволяет им «подслушивать» проходящие через них IGMP-сообщения и самостоятельно на них реагировать. «Подслушав» запрос на подключение к мультикастовой группе и считав адрес этой группы, коммутатор с этой функцией направляет полученный в ответ поток на порт, с которого поступил запрос. Затем он выявляет просьбу об отключении от мультикастовой группы и перестает пропускать поток с соответствующим адресом на порт, с которого пришла просьба. Таким образом, IGMP snooping в сочетании с IGMP v.2 исключает передачу лишнего мультикастового трафика через коммутаторы доступа. Аналогично работает модификация IGMP-протокола, разработанная фирмой Cisco — CGMP (Cisco Group Management Protocol). Эта функция требует достаточно много памяти и более высокой процессорной мощности, чем типичная для обычных домовых коммутаторов, что, разумеется, делает их дороже обычных. Тем не менее, в сетях c услугой IPTV без этой функции обойтись нельзя. Третья версия IGMP отличается от второй в основном тем, что позволяет абонентскому устройству составлять перечень тех источников, из которых он хочет принимать потоки, и тех, из которых не хочет.
Помимо обмена сообщениями в рамках IGMP, источник мультикаста может формировать SAP (Service Announcement Protocol) сообщения. Они передаются в вещательном режиме и содержат информацию о доступных мультикастовых потоках. Формирование SAP является факультативной функцией, но большинство устройств ее поддерживает.
Анна Бителева
По материалам семинара WISI 2009 года. © Теле-Спутник
