Пропускная способность становится драгоценным товаром, поэтому администраторы сетей ищут более эффективные способы доставки информации по сети.
Аудио/видео реального времени и технологии принудительного распространения чувствуют себя в корпоративных сетях все увереннее, что ведет к быстрому исчерпанию имеющейся пропускной способности. Некоторые организации решают эту проблему за счет увеличения пропускной способности, переходя к более быстрым сетям типа ATM и Gigabit Ethernet. Однако для многих из тех, кто сталкивается с нехваткой пропускной способности, такая отверточная замена оказывается чересчур дорогим удовольствием. Если вы вынуждены обходиться имеющимися ресурсами, то наилучшим решением является многоадресная передача по IP.
ОСНОВЫ МНОГОАДРЕСНОЙ ПЕРЕДАЧИ
Определенная IETF в 1989 году, эта технология передачи от одного ко многим пользовалась чрезвычайным успехом в узких кругах, но только в последний год она получила широкое признание.
Многоадресная передача по IP определена в документе RFC 1112, озаглавленном "Расширения хостов для многоадресной передачи по IP". Эта технология разрабатывалась для обеспечения более эффективной рассылки информации по IP-адресам, чем традиционные методы одноадресной и широковещательной передачи. При одноадресной передаче двухточечные соединения устанавливаются между каждым отправителем и получателем - даже если один отправитель посылает одно и то же сообщение или файл нескольким получателям. При всей своей эффективности для коммуникации каждого с каждым, например для электронной почты или просмотра Web, одноадресная передача понапрасну расходует пропускную способность, когда одинаковые пакеты необходимо отправить нескольким конечным станциям.
Другим способом передачи данных из одного места в другое является широковещательная передача, когда станция направляет пакеты всем конечным узлам независимо от того, нужны ли они им. Во многих ситуациях такой способ передачи также оказывается неэффективен.
В случае многоадресной передачи отправитель передает сообщение только один раз, затем оно тиражируется и доставляется только хостам, являющимся членами данной группы многоадресной рассылки. Такой режим экономит пропускную способность за счет передачи только того трафика, который необходим.
Чтобы иметь возможность участвовать в многоадресной передаче, и отправитель, и получатель должны поддерживать Internet Group Management Protocol (IGMP), входящий в стек протоколов TCP/IP, в том числе имеющийся в Windows 95 и Windows NT. Кроме того, IGMP должен поддерживаться и сетевыми маршрутизаторами. Используя этот протокол, клиенты сообщают маршрутизатору, в каких сеансах они хотят участвовать. Многоадресный пакет передается затем от маршрутизатора к маршрутизатору и далее к конечным узлам (см. Рисунок 1).
Distance Vector Multicast Routing Protocol широко применяется в Mbone. Данный протокол многоадресной маршрутизации пересылает пакеты избирательно, так что их получают только те маршрутизаторы, в подсетях которых есть члены группы; это позволяет эффективно использовать пропускную способность. DVMRP время от времени реконструирует дерево, так как членство в группе является динамическим.
Различные протоколы многоадресной маршрутизации опираются на различные подходы, но все они в конечном итоге сводятся к построению дерева Spanning Tree, связывающего все хосты в многоадресной группе. Эти протоколы осуществляют постоянный мониторинг Spanning Tree и обрезают, или исключают, ветви дерева, не ведущие к членам группы многоадресной рассылки.
Среди этих протоколов Distance Vector Multicast Routing Protocol, Multicast Open Shortest Path First и Protocol Independent Mul-ticast. (Дополнительную информацию о многоадресных IP-маршрутизаторах и протоколах маршрутизации смотри во врезке "Маршрутизация где возможно", а также в статьях М. Кульгина "От одного ко многим" и "Путеводный вектор и другие" в сентябрьском и октябрьском номерах журнала LAN за прошлый год.)
Членство в многоадресной группе является динамическим, поскольку конечные узлы могут присоединяться или выходить из группы в любой момент времени, к тому же они могут быть членами нескольких групп. Члены группы получают IP-адреса из пула адресов класса D, зарезервированных специально для многоадресной передачи. В стандартной нотации IP-адрес представляет собой четыре числа, разделенные точками; адреса класса D занимают пространство от 224.0.0.0 до 239.255.255.255. Адреса класса D служат для идентификации групп хостов, поэтому многоадресным маршрутизаторам нет необходимости хранить информацию о каждом члене группы. Вместо этого они просто направляют IP-пакет на адрес группы, так что его может получить любая конечная станция с поддержкой многоадресной передачи.
Помимо членства в группе хостов многоадресной рассылки передающая и принимающая станции должны отвечать еще нескольким требованиям, прежде чем они смогут воспользоваться преимуществами многоадресной передачи по IP. Так, стек TCP/IP, сетевой драйвер и сетевой интерфейс на конечной станции должны поддерживать многоадресную передачу.
На уровне сетевой инфраструктуры поддерживать многоадресную передачу по IP должны маршрутизаторы и операционные системы. К счастью, многие маршрутизаторы и ОС уже имеют такую встроенную поддержку. Если говорить о сетевых ОС, эта технология реализована в IntranetWare компании Novell, Windows NT компании Microsoft и в основных разновидностях UNIX, в том числе HP-UX, AIX и Sun Solaris. Если говорить о маршрутизаторах, многоадресную передачу по IP осуществляет оборудование таких крупнейших производителей, как Cisco, 3Com и Bay Networks.
МНОГОАДРЕСНАЯ ПЕРЕДАЧА В МАССЫ
Несмотря на возможность обеспечить более надежную и эффективную доставку данных как традиционных, так и реального времени и несмотря на свое достаточно долгое присутствие на рынке, многоадресная передача по IP долгое время не находила широкого распространения.
Как Internet была исключительно областью интересов научных и военных кругов, так и многоадресная передача по IP использовалась только несколькими технически развитыми организациями. Однако с появлением многоадресной магистрали (Multicast Backbone, MBone) такая ситуация начала постепенно меняться.
Mbone представляет собой подмножество Internet, поддерживающее многоадресный трафик. Эта магистраль используется для широковещательной передачи в реальном времени, например для конференций, встреч и даже рок-концертов. Несмотря на свою весьма скромную популярность среди пользователей Internet, в том числе из корпоративных организаций, Mbone дала настоящий толчок многоадресной передаче по IP, став тестовой площадкой для этой технологии. "Internet долгое время была исследовательской сетью. Mbone проделывает тот же путь", - говорит Мартин Халл, ведущий инженер в Stardust Technologies.
Несмотря на то что Mbone являет собою яркий пример успешного применения многоадресной передачи по IP на практике, многие администраторы сетей весьма настороженно относятся к идее ее развертывания в своих сетях. Недавнее исследование, проведенное Collaborative Research, показывает, что основными факторами, сдерживающими широкомасштабное распространение технологии, являются непонимание мультимедийных стандартов, реализаций провайдеров Internet и вопросов защиты, а также того, как многоадресная передача повлияет на функционирование сети (см. Рисунок 2).
Как видно из диаграммы, респонденты опроса, проведенного Collaborative Research, осознают преимущества многоадресной передачи по IP, но приводят массу доводов, почему они не торопятся с внедрением этой технологии.
Брайан Хилл, директор по исследованиям в Collaborative Research, утверждает: "Теперешние пользователи многоадресной передачи по IP - это первые ласточки. Они готовы взять на себя риск первопроходцев, так как считают, что эта технология является настоящим прорывом, и надеются извлечь значительную выгоду от ее применения". Среди таких пользователей сервис-провайдеры, финансовые организации и компании, имеющие корпоративные сети Intranet.
Чтобы ликвидировать недоверие к Mbone и многоадресной передаче по IP, группа компаний во главе с Precept Software и Stardust Technologies образовала осенью 1996 года IP Multicast Initiative (IPMI). Своей целью новая организация поставила просвещение производителей и заказчиков относительно достоинств технологии (см. врезку "Где найти дополнительную информацию").
Джуди Эстрин, основатель, президент и исполнительный директор Precept, производителя IP/TV, сетевого приложения для потокового мультимедиа, говорит: "Начав продавать продукт, мы полагали, что многоадресная передача более популярна, чем это было на самом деле, но вскоре поняли, что многие не осознают, что это такое. Именно тогда мы и решили организовать группу для решения просветительских задач в этой области".
За последний год число членов IPMI увеличилось до 65. Среди них создатели сетевых операционных систем Novell и Microsoft, производители сетевого оборудования 3Com, Bay Networks, Cabletron, Cisco, Hewlett-Packard, IBM и Sun Microsystems, спутниковые компании Hughes Network Systems и Intelsat; а также разработчики программного обеспечения Starlight Networks, White Pine Software, FTP Software и другие. Руководит группой Stardust, известная своей лабораторией для тестирования на совместимость с Winsock, а также новейшими сервисами Internet. Группа имеет сервер Web, на котором заинтересованный читатель может найти множество технических описаний и другой полезной информации. Кроме того, она проводит образовательные семинары в рамках отраслевых выставок, например на Networld+Interop.
Учитывая число производителей, присоединившихся к IPMI, любопытный наблюдатель может спросить, почему это произошло именно в 1997 году. Эстрин имеет на этот счет пару предположений. Она указывает на наметившиеся недавно тенденции, которые вывели на сцену потоковое аудио/видео и, как следствие, многоадресную передачу по IP, играющую важную роль в поддержке приложений реального времени.
Первая тенденция - увеличение доли процессоров Pentium и быстрых шин PCI в настольных системах: многие из этих систем имеют теперь достаточную вычислительную мощь для поддержки потокового мультимедиа. Вторая тенденция - повсеместное распространение сетей на базе IP и переход к коммутируемым локальным сетям, благодаря чему настольные системы получают в свое распоряжение большую пропускную способность. Среди других своевременно появившихся разработок она отмечает такие стандарты IETF, как протокол передачи в реальном времени (Real-Time Transport Protocol, RTP) и стандарты сжатия MPEG и H.261.
ЧТО ЕСТЬ НА РЫНКЕ
При таком количестве производителей, развивающих и продвигающих технологию многоадресной передачи по IP, выигравшими являются заказчики или конечные пользователи, так как они вскоре обнаружат, что некоторые приложения Internet реального времени стали выполняться гораздо более эффективно с использованием многоадресной передачи по IP.
Однако данная технология подходит далеко не для каждого приложения Internet; ее вряд ли имеет смысл использовать для IP-телефонии, просмотра Web или электронной почты, так как эти приложения предусматривают обычно взаимодействие двух конечных узлов, а не одного узла со многими. Но некоторые типы приложений не только функционируют более эффективно в результате реализации многоадресной передачи по IP в рамках сети компании, но и вообще обязаны ей своим появлением.
По мнению Халла из Stardust, наибольшие преимущества от многоадресной передачи получают такие приложения, как потоковое аудио/видео, принудительное распространение и электронное распространение приложений. Это связано, по его словам, с тем, что все они имеют одну общую особенность: "Им требуется передавать большие объемы одинаковой информации через существующую инфраструктуру".
Среди приложений потокового аудио/видео - дистанционное обучение, телемедицина, видео в настольных системах, корпоративные образовательные семинары и передача новостей. Эти приложения предлагаются такими компаниями, как Adaptive Media, AudioNet, Databeam, ICAST, Media4, Netcast, Precept, Progressive Networks, Starlight Networks, VDOnet, Vivo, Vxtreme и White Pine Software.
Сети пакетной коммутации типа Ethernet не обеспечивают гарантированного качества услуг, как ATM. Однако несколько протоколов были разработаны специально для решения этой проблемы, чтобы организации могли использовать имеющуюся инфраструктуру и для решения новых задач. В большинстве сетей пакетной коммутации, в том числе и Internet, протоколом транспортного уровня служит TCP. Это весьма надежный протокол, так как он имеет механизмы обнаружения ошибок и контроля трафика, но эти меры обеспечения надежной доставки информации не подходят для данных реального времени. Часто TCP передает информацию со значительными задержками и перерывами, что приводит к потере кадров, в результате речь или видеоряд воспроизводятся с искажениями и паузами.
RTP - стандарт IETF, опирающийся на многоадресную передачу по IP, - описывает механизм передачи данных, оптимизированный для доставки данных реального времени, таких как речь и видео. Используемый в Mbone, RTP помещает в заголовок пакета информацию о пакете, его порядковом номере и отметку о времени для корректного воспроизведения кадра. Связанный с ним протокол управления передачей в реальном времени (Real-Time Transport Control Protocol, RTCP) обеспечивает обратную связь между приложениями, предоставляя информацию о загруженности сети и качестве воспроизведения, чтобы приложения могли внести необходимые коррективы по ходу передачи.
Несмотря на то что он пока находится на стадии испытаний, протокол резервирования ресурсов (Resource ReserVation Protocol, RSVP) позволяет приложениям запросить необходимое качество услуг у сети. Хост RSVP посылает запрос сетевым маршрутизаторам, находящимся между отправителем и получателем; сеть резервирует пропускную способность и разрывает сеанс по его завершении. Благодаря RSVP мультимедийные приложения получают наивысший приоритет на такие сетевые ресурсы, как пропускная способность.
Если пропускной способности не хватает, то использование RSVP вряд ли чем поможет, но в нормальных условиях протокол позволяет обеспечить адекватную работу многих приложений реального времени.
ЦЕНТР РАСПРОСТРАНЕНИЯ
Электронное распространение приложений - еще один сервис, которому многоадресная передача по IP дает несомненные преимущества, потому что он предусматривает посылку одинаковой информации, часто весьма больших файлов, нескольким узлам и конечным пользователям.
Starburst Communications разработала приложение многоадресной передачи файлов по IP, с помощью которого компании могут производить массовое распространение очень крупных файлов. Протокол многоадресной передачи файлов (Multicast File Transfer Protocol, MFTP), интегрированный в потоковое программное обеспечение NetShow компании Microsoft, и продукт для распространения программного обеспечения AutoXfer компании Platinum Technology опираются оба на многоадресную передачу по IP и оптимизированы для целей распространения программного обеспечения.
MFTP находит пользователей на основании групповых адресов класса D. Каждый хост в группе идентифицируется адресом класса C (или обычным адресом), а класс D идентифицирует группу многоадресной рассылки, к которой каждый хост принадлежит.
Многие из компаний, использующих технологию Starburst, имеют штаб-квартиру и множество удаленных узлов, представляющих собой почти идентичные копии друг друга в смысле сетевой конфигурации, как утверждает Стефан Коллинз, вице-президент по маркетингу и развитию бизнеса в Starburst.
До внедрения многоадресной передачи компании, отвечающие этому определению, осуществляли передачу программного обеспечения и информации с помощью спутниковых сетей, при которой - когда сеансов точка-точка 500 или 1000 - пропускная способность теряется по большей части попусту.
Используя многоадресную передачу, эти компании могут ограничиться передачей одного файла по спутниковой сети, причем информация поступит всем адресатам одновременно без организации множества сеансов.
ОСОЗНАННАЯ НЕОБХОДИМОСТЬ
Несмотря на всю его важность самого по себе, электронное распространение программного обеспечения можно рассматривать как подмножество приложений другого типа, словно ждавшего многоадресной передачи, чтобы выйти на сцену технологии принудительного распространения.
Летом 1996 года, когда клиентское программное обеспечение PointCast Network получил возможность загружать всякий, кто имеет модем, администраторы сетей в США стали сталкиваться с существенным замедлением сетей. Только представьте, что все пользователи связываются с PointCast во время обеда и скачивают последние новости и информацию, причем каждый из них инициирует соединение точка-точка для получения по сути одной и той же информации.
Этот период незаконного захвата пропускной способности может закончиться навсегда с появлением нового поколения так называемых "истинных" технологий принудительного распространения. Они обеспечивают автоматическую доставку информации клиентам, подписавшимся на конкретную услугу - от аудио и видео до записей из баз данных и страниц Web. В большинстве случаев доставляемое с помощью истинных технологий принудительного распространения информационное наполнение отправляется в фоновом режиме без участия пользователя.
Одной из таких технологий является BackWeb, "умное" программное обеспечение сервера принудительного распространения компании BackWeb Technologies. С помощью серверов BackWeb компании могут настраивать каналы так, чтобы они автоматически доставляли информацию клиентам через Intranet и Internet. С другой стороны, в таких решениях, как PointCast, пользователи вынуждены поддерживать соединение все время активным или самостоятельно его устанавливать, если они хотят получать обновления.
BackWeb имеет встроенные средства поддержки многоадресной передачи IP от Tibco для доставки мультимедийной информации в реальном времени тысячам пользователей. "Мы хотели разрешить проблему нехватки пропускной способности, возникшую в результате разработанной нами технологии, - говорит Дэвид Баклэнд, главный менеджер по продуктам в BackWeb Technologies. - Наша технология увеличивает трафик в локальной сети, поэтому поддержка многоадресной передачи позволяет осуществлять истинное принудительное распространение данных многочисленным пользователям [без чрезмерной загрузки сети]". BackWeb разработала нечто, что компания назвала "протоколом вежливого поведения", или, если говорить по существу, протокол на базе UDP для загрузки информации на клиенты, когда сетевые соединения не заняты.
BackWeb объединила свои усилия с McAfee в целях создания SecureCast, службы распространения программного обеспечения, использующей технологию принудительного распространения для доставки обновлений антивирусного продукта VirusScan производства McAfee. "Многоадресная передача позволяет нам значительно экономить пропускную способность при доставке обновлений VirusScan по сравнению с HTTP", - рассказывает Баклэнд.
Чтобы подписаться, заказчикам необходимо обратиться на сервер Web компании McAfee (www.mcafee.com) и загрузить клиент SecureCast BackWeb. С этого момента пользователь может автоматически получать обновления с сервера BackWeb компании McAfee.
БЫСТРОЕ РАЗВЕРТЫВАНИЕ
Как мы упоминали ранее, многоадресная передача по IP предъявляет специфические требования на уровне как клиента, так и сети, однако если компания решит взять на вооружение новую технологию, то ей не придется делать значительные вложения и предпринимать заметные усилия.
Халл из Stardust утверждает, что, если компания заинтересована в развертывании многоадресной передачи, первое, на что она должна обратить внимание, - это окупаемость вложений и обоснование затрат. "Все новые приложения Internet разрабатываются исходя из парадигмы предоставления все больших объемов данных все большему числу пользователей, - говорит он, - пропускная способность Ethernet, Fast Ethernet и линий T-1 быстро исчерпывается, когда они служат в качестве среды передачи для обновлений программного обеспечения, принудительного распространения мультимедийного наполнения и потокового аудио/видео".
Скорее всего ваши операционные системы и маршрутизаторы поддерживают многоадресную передачу, так что остается ее только активизировать. Если же нет, то найти необходимые обновления не составляет труда.
Эстрин из Precept добавляет, что многие заказчики создают пробные сети с многоадресной передачей в своих лабораториях, чтобы проработать вопросы инфраструктуры, связанные с настройкой многоадресной передачи или модернизацией настольных систем.
Практически все, кто имеет отношение к технологии многоадресной передачи, соглашаются с тем, что она получила бы мощный стимул к развитию, если бы крупнейшие провайдеры Internet взяли ее на вооружение и предложили ее в качестве дополнительной услуги.
Халл даже предлагает стратегию: провайдеры Internet агрегируют информационное наполнение типа передачи новостей и финансовой информации и предлагают его за дополнительную плату. К сожалению, провайдеры Internet не спешат воспользоваться этой возможностью, так как они чересчур заняты круглосуточным обслуживанием.
"Мы бы хотели, чтобы провайдеры Internet обратились к многоадресной передаче", - говорит Коллинз из Starburst. Баклэнд из BackWeb соглашается с ним в том, что провайдерам Internet следовало бы более активно поддерживать многоадресную передачу, тем более что она дает реальные преимущества, только когда реализована "из конца в конец".
Если исходить из того, что провайдерам Internet приходится передавать умопомрачительные объемы трафика по всему миру, то логично предположить, что они должны были бы уже реализовать многоадресную передачу, но, к сожалению, этого не произошло. Один из способов указать им на важность данной технологии - всем миром обращаться к ним с просьбами о предоставлении услуг многоадресной передачи. Если такие просьбы будут постоянными, то тем самым можно заставить обратить их внимание на многоадресную передачу и даже реализовать ее.
Одной из областей, в которой и провайдеры Internet, и поставщики информационного наполнения, и производители сетевого оборудования, и конечные пользователи заинтересованы в равной мере - это проект Internet Multicast Channel (IMC), предложенный рабочей группой Internet Transition Working Group из IPMI. Многоадресный канал Internet, начавший работать в сентябре 1997 года, должен продемонстрировать провайдерам Internet, что им следует расширить спектр своих услуг, чтобы выделиться среди конкурентов.
Но даже если ваш сервис-провайдер, а также некоторые подразделения вашей организации не поддерживают многоадресной передачи, вы тем не менее можете извлечь преимущества из этой технологии с помощью так называемого туннелирования. Туннелирование предусматривает инкапсуляцию многоадресных пакетов в одноадресные пакеты для маршрутизации их через ту часть Internet, где многоадресная маршрутизация не поддерживается. Данная технология может служить промежуточным этапом на пути к полномасштабному развертыванию многоадресной передачи.
После того как основные провайдеры Internet и другие организации станут наконец-то реализовывать многоадресную передачу, следующим вопросом станет, вероятно, совместимость. Далеко не все они используют одни и те же маршрутизаторы или протоколы маршрутизации, так что если одна компания имеет маршрутизаторы Cisco с протоколом многоадресной маршрутизации PIM, а другая - маршрутизаторы Bay Networks с протоколом DVMRP, то взаимодействие с использованием наличествующих средств многоадресной передачи может потребовать установки шлюза. Эта задача не из легких, но долгое существование Mbone доказывает, что многоадресные сеансы можно организовывать и между несхожими сетями и что организации могут извлечь гораздо больше из того, что у них есть.
Анита Карве - помощник редактора Network Magazine. С ней можно связаться по адресу: akarve@mfi.com.
ПРОТОКОЛЫ МНОГОАДРЕСНОЙ МАРШРУТИЗАЦИИ ДЛЯ IP
Маршрутизация, где возможно
Один из этапов подготовки к развертыванию многоадресной передачи по IP в корпоративной сети состоит в проверке поддержки маршрутизаторами этого типа трафика. Протоколы многоадресной маршрутизации опираются на различные подходы, но все они создают Spanning Tree, связывающее все хосты в группе многоадресной рассылки. Дерево включает маршрутизаторы и хосты и описывает наиболее эффективный путь доставки информации от отправителя к получателю.
Многие из протоколов многоадресной маршрутизации применяются при большой плотности группы, иными словами, когда по крайней мере один член группы имеется в каждой подсети.
Описанный в RFC 1075, Distance Vector Multicast Routing Protocol (DVMRP) предназначен именно для таких сетей. DVMRP исходит из предположения, что все хосты в сети принадлежат к определенной группе многоадресной рассылки, поэтому вначале маршрутизатор-инициатор рассылки передает многоадресные сообщения всем связанным с ним маршрутизаторам. Принимающий маршрутизатор проверяет факт получения сообщения по кратчайшему пути до отправителя. Если этот факт подтверждается, то он передает сообщение дальше всем связанным с ним маршрутизаторам (естественно, за исключением того, от которого он его получил). Если же факт не подтверждается, то сообщение игнорируется. Данный процесс известен как "проверка обратного пути" и служит для предотвращения образования петель в дереве маршрутов. Процесс продолжается, пока сообщение не достигнет всех членов группы. Кроме того, DVMRP исключает ветви маршрута, если они не ведут к членам группы.
Другой протокол для сетей с высокой плотностью членов групп в подсетях - Multicast Open Shortest Path First (MOSPF), определенный в RFC 1584. Этот протокол, опирающийся на обычный OSPF, позволяет маршрутизаторам MOSPF отправлять многоадресные сообщения по кратчайшему пути от отправителя к получателю. Маршрутизаторы ведут учет членов группы и модифицируют информацию, так что сетевая топология всегда отражает реальное состояние сети.
Protocol Independent Multicast-DM (PIM-DM), хотя и находится в стадии разработки, поддерживается тем не менее некоторыми маршрутизаторами, в том числе производимыми Cisco. Как и DVMRP, этот протокол использует метод контроля обратного пути для создания дерева маршрутов. Но, в отличие от DVMRP, PIM-DM работает независимо от протокола одноадресной маршрутизации.
Сети с ограниченной пропускной способностью, в которых члены групп встречаются редко, используют другие протоколы. Один из них - PIM-SM (где SM означает Sparse Mode, или разреженный режим). Поддерживающие данный протокол маршрутизаторы посылают многоадресный трафик только тем маршрутизаторам, через которые он должен действительно проходить, чтобы достичь адресатов. Это позволяет создать эффективное дерево доставки.
Другой протокол для разряженных сетей - Core-Based Tree (CBT), создающий общее дерево доставки от базового маршрутизатора. Для того чтобы присоединиться к группе, маршрутизаторы посылают сообщение базовому маршрутизатору. В ответ базовый маршрутизатор отправляет подтверждение (оно служит также для включения маршрутизатора в качестве ветви дерева).
КАК СТАТЬ ЧЛЕНОМ IPMI
Где найти дополнительную информацию
IP Multicast Initiative (IPMI) была создана осенью 1996 года компаниями Precept Software и Stardust Technologies и насчитывает теперь несколько десятков членов. Организация поставила своей целью просвещение производителей и заказчиков относительно преимуществ Multicast Backbone и многоадресной передачи по IP.
Информацию о том, как вступить в IPMI, а также техническую документацию можно найти на сервере этой организации www.ipmulticast.com.
Если вы хотите получить копию "Отчета об использовании многоадресной передачи по IP", то обратитесь на узел Web компании Stardust Technologies по адресу: www.stardust.com.