Раздел: Документация
0 ... 3 4 5 6 7 8 9 ... 55 устройств, осуществляющих пакетную передачу данных (концентраторов, маршрутизаторов, коммутаторов, адаптеров ЛВС), с целью поддержки режимов передачи мультимедиа потоков, чувствительных к временным задержкам [12]. Проблемы использования приложений КВКС в локальных вычислительных сетях и в глобальной сети Интернет являются в своей основе общими, что определяется широким применением стека IP-протоколов в ЛВС и технологией коммутации пакетов, используемой в обеих сетях. Неизохронность пакетного трафика, являющаяся принципиальным недостатком технологии коммутации пакетов при передаче данных, чувствительных к задержкам, особенно сильно проявляется в условиях большой загрузки сетевых каналов. Последнее является характерной особенностью для среды Интернет. Поэтому снижение интенсивности генерации мультимедиа трафика - это наиболее естественное решение задачи обеспечения заданного уровня QoS в таких сетях. Одним из способов решения этой проблемы является групповая адресация и маршрутизация (IP-multicasting). Кроме этого, возможности функционирования приложений КВКС в IP-сетях связаны с разработкой транспортных протоколов, позволяющих осуществить резервирование требуемых сетевых ресурсов для конкретных приложений и обеспечить управление передачей потоков данных реального времени. Обстоятельное рассмотрение технологии групповой передачи данных и протоколов реального времени проводится в главе 5. Ниже приводится лишь краткий их обзор. В марте 1992 года группа исследователей, работающих над проблемами совершенствования функционирования сети Интернет, успешно провела смелый эксперимент - на основе телекоммуникационной структуры Интернет ими была организована многосторонняя компьютерная конференция в реальном времени. Большая часть участников конференции располагались в Калифорнии (США). Вместе с ними работали специалисты из Великобритании, Швеции и Голландии. Таким образом, впервые было доказано, что среда Интернет может с успехом применяться для приложений реального времени. Вторым результатом этого события явилось повышение внимания к сетевым технологиям, обеспечивающим передачу трафика аудио/видео приложений реального времени по IP-сетям и, как следствие, создание экспериментальной сети Mbone. Сегодня, общедоступная часть этой сети образуется объединением более 3200 локальных сетей, а в ее работе принимают участие более 10 ООО организаций во всем длире. Технологической основой сети Mbone явилась групповая адресация и маршрутизация графика (подробнее смотри главу 5). Ее особенность заключается в возможности приема IP-пакетов с групповыми адресами всеми членами определенной группы, что исключает необходимость множественной пересылки копий этого пакета от источника ко всем участникам группы. Такой механизм адресации дает существенную экономию дефицитного ресурса - пропускной способности каналов Интернет, и как нельзя лучше удовлетворяет потребностям групповых видеоконференций. За прошедшие годы технология групповой адресации усилиями инженерной группы Интернет (IEFT) в значительной мере стандартизирована. Определяющим документом, является RFC1112. Практически все крупные производители сетевого оборудования и программного обеспечения вводят в свои продукты поддержку групповых технологий. К сожалению, большинство работающих в настояще время сетевых коммутационных устройств пока не располагают такими возможностями. В таких условиях для обеспечения работы групповых приложений используется технология IP-туннелирования, когда пакеты с групповыми адресами помещаются в обычные IP-пакеты с адресом назначения, соответствующим маршрутизаторам, распола!ающим возможностями обработки группового трафика. В настоящее время сеть Mbone используется, главным образом, для проведения групповых видеоконференций. Рекомендации Н.323, определяющие функционирование систем КВКС в IP-сетях, включают необходимость поддержки групповой адресации для организации конференций со множми участниками В число коммерческих продуктов КВКС, в которых реализован указанный сервис, входят системы InPerson (Silicon Graphics), IVS (Inria), Соттитдий (InSoft) и ряд других. Вместе с тем, все более популярными становятся приложения сетевого широковещания Первоначально они строились исключительно на фирменных протоколах групповой передачи (RealNetwork, Xing, VDOnet, и т.д.), но в последнее вредля отчетливо ьидна тенденция перехода к стандартным решениям и в этой области. Сеть Интернет и стек протоколов TCP/IP создавались для обеспечения надежной передачи данных в условиях отсутствия сколько-нибудь ограничивающих требований к задержке их транспортировки. Мультимедиа данные, потенциально содержащие значительную долю группового трафика, предъявляют в этой части существенно более жесткие требования и, соответственно, нуждаются в другом наборе протоколов фанспортного уровня. Действительно, механизмы повторной передачи испорченных (потерянных) пакетов и алгоритм регулирования размера окна передачи, используемые в протоколе TCP, ддогут являться причиной фатальных нарушений воспроизведения данных реального времени. К числу недостатков стека протоколов TCP/IP для такого вида трафика следует отнести его неспособность обеспечить маршрут с гарантированным и стабильным качестводл обслуживания, а также отсутствие в заголовке пакета TCP временных меток, что очень важно для синхронизации воспроизведения аудио/видео информации. При этом для многих алгоритмов воспроизведения мультимедиа приложений уровень надежности доставки пакетов, обеспечиваемый TCP, является избыточным. Учитывая перечисленные факторы, был разработан ряд протоколов, совершенствующих архитектуру сетей, использующих стек IP-протоколов (Интернет, интранет-сети) в части поддержки приложений ре-члиюю времени. В число этих протоколов входят RTP (Real-Time Transport Protocol) [12], RTCP (Real-Time Conkol Prolocol), RSVP (Resource Reservation Protocol) и некоторые другие. Все перечисленные протоколы разрабатывались для поддержки передачи как одноадресного, так и группового трафика, поэтому характеристики технологии IP-multicasting ими учитываются в достаточно полной мере. Real-Time Transport Protocol (RTP) - протокол, обеспечивающий сервис по транспортировке данных из конца в конец для приложений реального времени. Он определен документами IETF - RFC1889 и RFC 1890. Этот протокол используется приложением vat (КВКС в Mbone на платформе UNIX) и многими коммерческими мультимедиа приложениями указанных выше классов. RTP сервис включает информацию о типе передаваемых данных, что позволяет применять его для передачи разнообразных медиа потоков, нумерацию пакетов и их временные метки. Последнее важно для синхронизации разных медиа компонент единого информационного потока и контроля степени неизохронности их доставки. Доставка RTP-пакетов контролируется и управляется протоколом RTCP (см. ниже). RTP-сессия определяется заданием IP-адреса и номеров двух портов - для RTP и RTCP. Для мультимедиа приложения открывается столько RTP-сессий, сколько медиа компонент генерируется этим приложением, т.е открываются отдельные сессии для аудио, видео и данных. Это позволяет приемному терминалу произвести выбор требуемого ему медиа потока. RTP не является в полном смысле протоколом транспортного уровня. В частности, он не поддерживает функции мультиплексирования и проверки контрольных сумм. Поэтому протокол RTP обычно используется совместно с UDP или другими транспортными протоколами. Real-Time Control Protocol (RTCP) - управляющий протокол, работающий совместно с RTP и выполняющий функции, аналогичные функциям ICMP. Все участники RTP-сессии периодически обмениваются пакетами RTCP-сообщений, ответы на которые используются для контроля производительности систем и в диагностических целях. RTCP реализует следующие основные функции. Обеспечение приложения информацией о качестве передачи его данных. Эксперименты с технологией групповой передачи показали важность наличия обратной связи от приемника к передающему приложению для диагностики нарушений доставки медиа данных. Каждый RTCP-пакет содержит сообщения о числе отосланных, числе принятых с ошибками и количестве потерянных пакетов. На основании этой информации могут быть приняты меры к снижению генерируемого трафика, локализации источника снижения качества приема, а также осуществлению мониторинга производительности сетевого сегмента. Идентификация источника RTP-пакетов. Пакет RTCP содержит идентификатор RTP-источника - «каноническое имя» (canonical name - CNAME). Он используется приемником, в общем случае принимающим мультимедиа данные от нескольких источников, для синхронизации м*едиа потоков, генерируемых одним источником. Ограничение трафика контрольных протоколов. Уровень контрольного трафика в сетевом» сегменте не должен превосходить 5% общего RTP-трафика. Эта обеспечивается регулированием частоты генерации RTCP-пакетов в зависимости от числа участников сессии. Resource Reservation Protocol (RSVP) - протокол резервирования ресурсов сетевых коммуникационных устройств для передачи одноадресного и группового трафика реального времени [13J Основной целью его применения является обеспечение гарантированного уровня качества обслуживания сетью определенного приложения. Уровень качества обслуживания на сетевом уровне определяется доступной емкостью коммуникационного канала и предельной величиной времени обработки пакета на каждом из сетевых устройств. Обеспечение заявленных приложением требований качества обслуживания требует резервирования определенных аппаратных ресурсов (производительности центрального процессора, объема оперативной памяти, размеров буферов и т.п.). В соответствии с протоколом RSVP решение этих задач производи 1ся посредством генерации ряда специальных сообщений, которые распространяются по маршруту, определенному используемым протоколом маршрутизации, от приемника к источнику сообщения. Таким образом, протокол обеспечивает резервирование ресурсов лишь в направлении от приемника к источнику. Для групповых приложений запросы от приемников объединяются в общих узлах дерева доставки в соответствии с определенными правилами (см. подробнее в главе 5). Протокол RSVP работает поверх протокола IP. Занимая в протокопьном стеке место протокола транспортного уровня, он выполняет функции протокола сессионного уровня, и является, по существу, управляющим протоколом (подобно IGMP и ICMP). Недостатком протокола является довольно высокая его требовательность к вычислительным ресурсадл, необходимым для проверки каждого приходящего пакета и принятия решения о приоритете его обработки. Рассмотренные выше протоколы в своей совокупности позволяют функционировать приложениям реального времени в IP-сетях. В этой связи отметим, что привлекательность использования таких приложений, как КВКС и аудио/видео широковещание в Интернет, заключается в значительной мере в относительной дешевизне транспортировки данных. Однако рост популярности этих систем порождает бурное увеличение загрузки сети и стимулирует Интернет-провайдеров к введению дифференцированной оплаты за разные виды трафика с увеличенными тарифадли на передачу аудио/видео информации. Кроме указанного направления исследований, связанного с созданием новых протоколов, поддерживающих мультимедиа трафик, проводятся также работы, направленные на модификацию самой технологической основы традиционных ЛВС. Можно выделить три направления модификации Ethernet [12]: - Priority Access Control Enabled (PACE) фирмы 3Com; -isoEthernet фирмы National Semiconductor; -lOOVG-AnyLAN фирмы Hewlett Packard. Общей целью всех этих усилий является попытка преодолеть главный недостаток сетей Ethernet, а именно неспособность отличить мультимедиа пакеты от обычных пакетов с данными. РАСЕ технология представляет собой решение корпорации 3Com, основанное на использовании РАСЕ - версий коммутаторов LinkSwitch 1000 и 3000, а также РАСЕ - драйверов для сетевых адаптеров EtherLink. Каждая рабочая станция имеет выделенный порт на РАСЕ - коммутаторе и, при необходимости, с помощью РАСЕ - драйверов назначает приоритет своим пакетам, что обнаруживается коммутатором и приводит, в конечном счете, к уменьшению числа конфликтов на конечных станциях. Технология IsoEthernet (изохронный Ethernet) объединяет сервис сетей ISDN с традиционными службами сети передачи данных Ethernet (средства 10Base-T) [12]. Определенные надежды могут быть связаны с использованием нового стандарта IEEE 802.9а для мультимедиа в локальных компьютерных сетях, базирующегося на таком решении. Передача аудио и видео данных осуществляется в сети с временным мультиплексированием по 96 В-каналам. Технология lOOVG-AnyLAN обеспечивает передачу данных со скоростью 100 Мбит/с по витой паре, причем центральный концентратор реализует обработку запросов с учетом приоритетов. Компания Hewlett Packard разрабатывает такую технологию, в частности, для обеспечения доступа к учебным видеопрограммам, а также для систем видеоконференцсвязи. Наряду с подобными частными решениями производители в настоящее время объединяют свои усилия на базе использования рассматриваемого ниже стандарта Н.323. Это обеспечит совместимость систем КВКС, используемых в ЛВС, с системами стандарта Н.320, работающими в ISDN. 1.4. ПРОБЛЕМА СОВМЕСТИМОСТИ. РЕКОМЕНДАЦИИ Н.32Х И Т.12Х Одним из важнейших условий использования систем КВКС как средства коллективной работы удаленных пользователей является совместимость программно-аппаратных средств таких систем. Тем не менее в течение достаточно длительного периода развития и использования систем видеоконференцсвязи наблюдалось многообразие методов компрессии аудио и видеоинформации, интерфейсов, протоколов обмена данными, когда обеспечивалась совместимость в лучшем случае продуктов одной и той же фирмы. Особенно ярко это проявлялось в студийной видеоконференцсвязи с использованием выделенных каналов (радиорелейных, спутниковых, оптоволоконных) и дорогого студийного оборудования. Такие видеоконференции каждый раз представляли собой уникальное, заранее подготавливаемое и достаточно дорогостоящее мероприятие и исключали возможность контакта с пользователями, начинающими приобретать настольные комплекты компьютерной видеоконференцсвязи. Бурно развивающийся рынок программно-аппаратных средств КВКС остро поставил вопрос о совместимости продуктов различных фирм и, следовательно, о необходимости стандартизации в сфере КВКС 1.4.1. Международные организации по стандартизации в области КВКС Основную роль в работе по стандартизации в области КВКС играют Международный Союз Электросвязи (International Telecommunication Union, ITU), Международная организация по стандартизации (International Organization for Standartization, ISO) и Международный консорциум мультимедийных телеконференций (International Multimedia Teleconferencing Consortium, IMTC). Приведем краткую характеристику областей их деятетельности. Международный Союз Электросвязи (BTU) является межправительственной организацией, обеспечивающей сотрудничество государственных и частных организаций в процессе создания документов, регламентирующих ключевые характеристики телесервиса и телекоммуникационного оборудования. В марте 1993 года в его составе были созданы ряд специализированных секторов, в частности сектор ITU-T, который принял на себя функции, ранее принадлежавшие организации International Telegraph and Telephone Consultative Committee (CCITT). Основной целью деятельности ITU-T является разработка, принятие, распространение и внедрение рекомендаций в области телекоммуникаций. Рекомендации могут быть преобразованы в национальные или международные стандарты только после принятия решения соответствующими организациями, такими как ISO (см.ниже). Эти рекомендации разрабатываются усилиями более чем 4000 экспертов из разных стран, объединенных в 16 специализированных групп (Study Groups) Таблица 1.1 отражает спектр вопросов, находящихся в поле зрения этих групп, и некоторые примеры разработанных рекомендаций. 0 ... 3 4 5 6 7 8 9 ... 55
|
