Мультимедиа в вашей сети

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

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

Стандартным ответом отрасли на вопрос относительно сетевого мультимедиа была фраза: "Ждите ATM". ATM с его масштабируемой пропускной способностью и гарантией качества услуг представляет собой идеальную инфраструктуру для поддержки мультимедийных приложений с жесткими требованиями к пропускной способности и задержке. Однако сегодня многие компании не испытывают потребности или не располагают достаточными средствами для развертывания ATM либо другой высокоскоростной технологии для магистрали. К счастью, технологии передачи пакетов и мультимедийные приложения продолжают совершенствоваться, так что компаниям для поддержки сетевого мультимедиа достаточно лишь несколько модернизировать инфраструктуру.

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

МУЛЬТИМЕДИЙНОЕ ПРИЛОЖЕНИЕ - ЧТО ЭТО ТАКОЕ?

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

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

Для такой непопулярности настольных систем конференций на базе локальных сетей есть несколько причин, среди которых отсутствие стандартов и несоответствие корпоративной сетевой инфраструктуры требованиям передачи интерактивного трафика в реальном времени. Однако принятие стандарта ITU H.323, определяющего видеоконференции на базе локальных сетей, а также появление новых протоколов, обеспечивающих качество услуг в сетях передачи пакетов, должны привести к более широкому распространению настольных систем видеоконференций на базе локальных сетей.

Стандарт H.323 описывает терминалы, оборудование и сервисы для мультимедийных коммуникаций по локальным и глобальным сетям, не гарантирующим качества услуг, таким как Ethernet, Token Ring и IP. Кроме того, стандарт призван обеспечить совместимость продуктов. H.323 определяет несколько новых сетевых компонентов, включая терминал (или клиент) H.323, диспетчер конференций и шлюз H.323. Диспетчер выполняет все обязанности, связанные с организацией конференций, а шлюз позволяет терминалам H.320 на базе ISDN взаимодействовать с терминалами H.323 на базе локальных сетей.

Системы H.323 имеют несколько преимуществ перед своими аналогами H.320. Во-первых, поскольку они используют существующую сетевую инфраструктуру, а не выделенные линии ISDN, то и их реализация обходится гораздо дешевле. Во-вторых, они предоставляют нечто большее, чем просто видеоконференции: они поддерживают использование разделяемых приложений, таких как конференции документов, благодаря чему пользователи могут вместе работать над различными проектами.

Система LiveLAN компании PictureTel являет собой пример настольной системы видеоконференции на базе локальной сети, отвечающей новому стандарту. Она состоит из трех компонентов - мультимедийного клиента, диспетчера и шлюза. Рисунок 1 иллюстрирует, какое место эти компоненты занимают в сети. Клиент включает аппаратный кодек по стандарту H.261, камеру и громкоговорители, а также программное обеспечение для совместного использования приложений. Диспетчер осуществляет контроль за доступом клиентов. С помощью этой функции администратор сети может выделить пропускную способность в каждом сегменте локальной сети для трафика конференции. При поступлении новой заявки на участие в конференции она одобряется или отвергается в зависимости от трафика в сети на данный момент. Благодаря контролю доступа администраторы могут гарантировать нормальное качество конференц-связи для всех участников, не опасаясь перегрузки сети. Как упоминалось выше, шлюз обеспечивает связь с системами H.320, использующими выделенные линии.

LiveLAN, когда она будет полностью совместима со стандартом H.323 (ориентировочно во втором квартале 1997 года), должна будет обеспечивать полное разрешение по стандарту общего промежуточного формата (Common Intermediate Format, CIF) 352x288 пикселов с частотой 15 кадров в секунду; при этом ей будет необходима пропускная способность 174 Кбит/с в каждом направлении или 348 Кбит/с в разделяемой локальной сети с двумя пользователями. Такой уровень трафика где-то на порядок больше, чем обычно генерируемый пользователем трафик данных, так что LiveLAN и другие аналогичные приложения могут оказать существенное влияние на инфраструктуру сети. Например, в разделяемом сегменте Ethernet на 10 Мбит/с пятьдесят пользователей будут генерировать трафик в 17 Мбит/с - это почти в два раза выше, чем номинальная пропускная способность данной сети. Поэтому при развертывании приложений для видеоконференций в сетях Ethernet и Token Ring надо иметь в виду, что пользоваться ими сможет только ограниченное число участников (ввести такое ограничение позволяет диспетчер конференций).

ВИДЕОНОВОСТИ И ИНФОРМАЦИЯ

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

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

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

MSNBC Business Video от компании MSNBC - одна из новых служб на рынке мультимедийных новостей. Зарегистрировавшись на узле Web компании MSNBC (www.businessvideo.msnbc.com), пользователи получают доступ к информационным сервисам в реальном времени, а кроме того, по требованию им могут быть предоставлены архивные материалы. Информация распространяется по Internet. Каждый пользователь генерирует сетевой трафик где-то около 28 Кбит/с, проходящий через корпоративный шлюз в Internet. Это весьма скромный уровень трафика - сравнимый с тем, который создают обычные приложения, а это означает, что приложения передачи мультимедийных новостей в реальном времени оказывают весьма небольшое влияние на вашу сеть.

ПОДГОТОВКА СЕТИ К МУЛЬТИМЕДИА

Если ваша организация испытывает реальную потребность в мультимедийных приложениях, таких как новости в реальном времени или настольные видеоконференции, то в вашем распоряжении достаточно возможностей для их развертывания без коренной переделки всей магистрали. Несмотря на ажиотаж, мультимедийные приложения внедряются довольно медленно - организации пытаются вначале выяснить, какие реальные выгоды они могут от этого получить. При правильном планировании тестовые или мелкомасштабные реализации этих приложений можно осуществить без каких-либо кардинальных изменений в вашей среде. Конечно, в случае крупномасштабного развертывания мультимедийных приложений сетевую магистраль наверняка потребуется модернизировать посредством внедрения ATM, IP-коммутации или Gigabit Ethernet. (Сравнительный анализ этих высокоскоростных технологий можно найти в июньском номере нашего журнала в статье "Модернизация магистрали".) Но если вы задумали провести только мелкомасштабную реализацию, то ключевой вопрос, стоящий перед вами, - как работать с тем, что вы уже имеете. Ниже изложено пять правил, следуя которым вы сможете подготовить вашу сеть для передачи мультимедийного трафика.

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

При анализе емкости и производительности вы должны начать с описания мультимедийных приложений, которые вы планируете развертывать. Рисунок 2 иллюстрирует анализ трафика, порождаемого системой LiveLAN (тесты были сделаны в феврале 1997 года для версии LiveLAN, на тот момент не совместимой со стандартом H.323). Средний трафик для одной видеоконференции с двумя участниками составил 450 Кбит/с; размер изображения - 176х144 пикселей. PictureTel утверждает, что данный уровень трафика значительно выше, чем тот, который LiveLAN будет иметь, когда станет полностью совместимой со стандартом H.323. (Как мы упоминали ранее, H.323-совместимая система от PictureTel предполагает наличие полосы пропускания шириной 384 Кбит/с для двустороннего трафика.) Зная порождаемый приложением трафик, вы сможете определить, где и в какой мере емкость необходимо увеличить и до какой степени вы должны ограничить число пользователей.

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

Простой анализ с помощью электронной таблицы источников трафика, нагрузки трафика на сеть и максимальной пропускной способности сетевых компонентов даст вам отправную точку для планирования модернизации инфраструктуры. Например, восьмипортовое сетевое устройство (коммутатор или маршрутизатор) должно пересылать 60 000 пакетов Ethernet в секунду для того, чтобы справиться с полной нагрузкой на все восемь портов. Иными словами, оно должно справляться с полной нагрузкой в 40 Мбит/с. Многие современные маршрутизаторы и коммутаторы обеспечивают достаточную емкость для небольших пакетов (нерегулярный трафик данных) и для больших пакетов (мультимедийный трафик). Однако если новейшие продукты отвечают требованиям, предъявляемым мультимедийным трафиком, то старые маршрутизаторы, коммутаторы или интерфейсное оборудование соответствуют этим требованиям далеко не всегда.

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

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

Многие администраторы сетей полагают, что сегмент локальной сети не должен быть загружен более чем на 35% от своей емкости. Это общее правило появилось несколько лет назад, когда локальные сети имели весьма значительную протяженность. Сегодняшние компактные сети 10BaseT могут передавать гораздо больший объем трафика практически с той же самой задержкой. Недавно автору пришлось производить мониторинг регулярных пакетов протокола Spanning Tree от коммутатора Ethernet компании Compaq в незагруженной и загруженной сети. Загруженная сеть была занята на 70-80% своей емкости. Как оказалось, время между прибытием регулярно рассылаемых пакетов в обоих случаях было одинаковым. Это означает, что вариация задержки для загруженной сети составляет менее 1 мс, а следовательно, вариация в случае мультимедийных приложений с низкими требованиями к пропускной способности будет составлять менее 1 мс в сильно загруженном сегменте 10BaseT. Однако если мультимедийное приложение использует более чем 2-3 Мбит/с пропускной способности в загруженной сети, то оно не сможет нормально работать само и не даст это делать другим приложениям.

2. Улучшите вашу инфраструктуру управления сетью. Мультимедийный трафик увеличит нагрузку на сетевую инфраструктуру даже в случае реализаций с низкими требованиями к пропускной способности. Чтобы справиться с этим трафиком, вам придется обновить свой инструментарий управления сетью. Он должен включать менеджеров SNMP, анализаторы протоколов и зонды RMON. Без современного оборудования управлять потоковым трафиком вы не сможете.

Большинство крупных организаций уже обзавелось менеджерами SNMP; такие компании должны удостовериться, что их новое мультимедийное оборудование имеет агентов SNMP. Например, шлюз H.323 должен быть SNMP-управляемым. Единственное исключение здесь составляют брандмауэры, которые мы рассмотрим в следующем разделе. Этими устройствами необходимо управлять по внешнему каналу, потому что доступ по сети, например через SNMP, может быть перехвачен хакером. Небольшим и средним организациям, еще не реализовавшим управление на базе SNMP, следует рассмотреть возможность приобретения относительно недорогих продуктов на базе Windows, таких как SNMPc от CastleRock Computing.

Помимо приобретения инструментария на базе SNMP вам потребуется обновить и инструментарий для анализа данных, такой как зонды RMON и переносные анализаторы протоколов. С помощью усовершенствованных продуктов Hewlett-Packard, Network General и Frontier Software администраторы могут оптимизировать работу мультимедийных приложений. Приобретая такое оборудование, не забудьте узнать о планах выбранного вами поставщика, касающихся поддержки анализа мультимедийных данных.

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

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

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

4. Обеспечьте качество услуг. Чтобы реализовать качество услуг в сети с маршрутизаторами, мультимедийному трафику необходимо предоставить приоритет. Это можно сделать несколькими способами. Маршрутизаторы можно настроить таким образом, чтобы конкретным потокам была гарантирована определенная пропускная способность и чтобы они имели приоритет над потоками данных. Выделение пропускной способности и определение трафика как приоритетного хороши, когда число отправителей и получателей мультимедийной информации невелико. Но с ростом их численности задание приоритетов на маршрутизаторах и коммутаторах потребует применения более динамической схемы. Для реализации такой схемы придется применять специальный протокол для передачи запросов о выделении ресурсов сетевым коммутаторам и маршрутизаторам, а также алгоритм для контроля доступа, принимающий решения об удовлетворении конкретных запросов.

RSVP - новый стандартный протокол IETF, с помощью которого конечные станции могут сообщать сети о своих потребностях в ресурсах для конкретных сервисов. (Дополнительную информацию о RSVP см. в этом номере в статье "RTP и RSVP: доставка в срок".) Станция, желающая зарезервировать полосу пропускания для мультимедийного трафика, посылает ближайшему маршрутизатору запрос, в котором, например, говорится: "Мне нужен канал на 3 Мбит/с к такому-то и такому-то адресату". Запрос передается по сети назад мультимедийному серверу. По пути его просматривают все маршрутизаторы; если маршрутизатор может выполнить содержащиеся в запросе требования, то он передает запрос следующему маршрутизатору. Запрос удовлетворяется, если все маршрутизаторы ответили утвердительно. Если какой-либо маршрутизатор по пути перегружен, то он ответит конечной станции сообщением "просьба отклонена".

RSVP представляет собой ответ IP на ATM, и производители маршрутизаторов уже предлагают первые реализации. Так, например, Cisco включила недавно RSVP в последнюю редакцию программного обеспечения маршрутизаторов Internetwork Operating System. Так что при необходимости вы можете обновить программное обеспечение имеющихся маршрутизаторов и конечных станций для поддержки RSVP.

Несмотря на все внимание, уделяемое RSVP, это только один из инструментов, которые сети передачи пакетов могут использовать, чтобы гарантировать качество услуг для мультимедийных приложений. Рабочая группа Integrated Services over Specific Link Layers (ISSLL) - подкомитет IETF - разрабатывает новые стандарты, благодаря которым устройства второго уровня, такие как коммутаторы Ethernet и Token Ring, смогут обеспечивать качество услуг. RSVP, изначально написанный для Internet, предназначен для сред, где используются главным образом устройства третьего уровня (то есть маршрутизаторы), соединенные прямыми линиями. Однако сегодняшние сети представляют собой "хитросплетение" коммутаторов, соединяющих клиентов, хосты и маршрутизаторы. При разработке стандартов для устройств второго уровня ISSLL учитывает и уже существующие стандарты, подобные RSVP. В результате должна быть создана сеть, где приложение может запрашивать качество услуг от устройств как третьего, так и второго уровня, используя RSVP. Детали приоритетов второго уровня для самих коммутаторов уточняются комитетом IEEE 802.1p.

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

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

Чтобы реализовать многоадресную рассылку в вашей сети, маршрутизаторы, коммутаторы, приложения и клиенты должны быть сконфигурированы на поддержку тех протоколов многоадресной рассылки, которые вы планируете использовать. Протоколы многоадресной маршрутизации включают Distance Vector Multicast Protocol, Multicast Open Shortest Path First и Protocol Independent Multicast.

Все эти протоколы выполняют специфичные функции многоадресной рассылки; ниже будет дан только общий обзор тех возможностей, которые они предоставляют. Станция-отправитель периодически извещает все маршрутизаторы о том, что сеанс многоадресной рассылки по-прежнему открыт. Всякий раз, когда клиент-получатель оповещает маршрутизатор с помощью протокола управления группой Internet (Internet Group Management Protocol, IGMP), что он хочет принять участие в сеансе, сеть прокладывает путь от отправителя к получателю. Другие неиспользуемые пути "отрезаются" от дерева доставки, так что по ним мультимедийные данные не передаются, и сеть попусту не загружается. Подробную информацию о функциях этих протоколов можно прочитать на узле Web компании 3Com в статье "Введение в многоадресную маршрутизацию" (www.3Com.com/nsc/501303.html).

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

ДОЖДАЛИСЬ!

С появлением все большего числа мультимедийных приложений с невысокими требованиями к пропускной способности и с ширящейся поддержкой H.323, RSVP и других стандартов сетевое мультимедиа наконец-то становится жизнеспособной технологией для многих организаций. Если ваша организация действительно нуждается в мультимедийном приложении, таком как видеоновости, совместные настольные видеоконференции, медицинское диагностирование или обучение, то успех подготовки имеющейся сети для работы с ними во многом зависит от вас. Все, описанное в этой статье, должно помочь вам и вашей организации. Заинтересованные читатели могут обратиться к книге Франсуа Флукигера "Что такое сетевое мультимедиа", вышедшей в издательстве Prentice Hall (Francois Fluckiger, Understanding Networked Multimedia, Prentice Hall, 1995).