RSS    

   Реферат: Мультимедия по IP

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

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

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

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

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

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

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

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

Резервирование ресурсов позволяет маршрутизаторам заранее определить, в состоянии ли они осуществить доставку многоадресного трафика всем получателям.

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

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

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

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

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

Спецификация фильтра определяет набор пакетов, под которые запрашиваются ресурсы. Вместе с сеансом она определяет набор пакетов (или поток), для которых требуемое качество услуг должно быть обеспечено. Любые другие пакеты, направляемые этому адресату, обрабатываются постольку, поскольку сеть в состоянии это сделать.

RSVP не определяет содержание спецификации потока, он просто передает запрос. Спецификация потока включает обычно класс услуг, Rspec (R означает резерв) и Tspec (Т означает трафик). Два других параметра представляют собой набор чисел. Параметр Rspec определяет требуемое качество услуг, а параметр Tspec описывает поток данных. Содержимое Rspec и Tspec прозрачно для RSVP

В принципе спецификация фильтра описывает произвольное подмножество пакетов одного сеанса (т. е. пакетов, адресат которых определяется данным сеансом). Например, спецификация фильтра может определять только конкретных отправителей или протоколы либо пакеты, поля протокольных заголовков которых совпадают с заданными.

С точки зрения хоста работа протокола состоит из следующих этапов (первые два этапа в этой последовательности имеют иногда обратную очередность)

1. Получатель вступает в группу многоадресной рассылки посредством отправки сообщения по протоколу IGMP соседнему маршрутизатору.

2. Потенциальный отправитель отправляет сообщение по адресу группы.

3. Получатель принимает сообщение Path, идентифицирующее отправителя.

4. Теперь, когда получатель имеет информацию об обратном пути, он может отправлять сообщения Resv с дескрипторами потока.

5. Сообщения Resv передаются по сети отправителю.

6. Отправитель начинает передачу данных.

7. Получатель начинает прием пакетов данных.

Механизм установка соединения с резервированием полосы пропускания.

            Процедура установки соединения с резервированием полосы пропускания проходит следующим образом:

            Конечный пользователь, заинтересованный в передаче чувствительного к задержкам трафика, передает в сеть сообщение с указанием информации о данных, которые он собирается передавать (сюда включается IP адрес источника и номер UDP/TCP порта),а так же информацию о типе трафика.

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

            При прохождении по сети этот информационный пакет “запоминает” маршрут по которому он дошел до получателя.

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

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

            Каждый промежуточный узел сети проводит анализ полученного запроса на основании описанных ниже правил.

            При получении запроса на установку соединения с резервированием ресурса в узле сети включаются два механизма: контроллер ресурсов канала, определяющий наличие запрашиваемого ресурса и контроллер доступа, сверяющий права данного пользователя с полученным запросом.

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

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

            Обработка запроса на установление соединения с резервированием ресурса проходит по отдельности  для каждого типа сетевого соединения так как протокол RSVP способен различать типы соединения.

            Тип сетевого соединения определяется тремя параметрами: IP адрес получателя, тип протокола и тип порта назначения.

            Если полученный запрос удовлетворяет всем требованиям, то узел производит резервирование необходимой полосы пропускания и передает запрос дальше, в направлении к передатчику.

            Как только передатчик получает запрос на резервирование полосы пропускания от приемника соединение считается установленным и начинается обмен информацией.

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

            Узел сети в праве прекратить резервирование полосы пропускания как только он не получает очередного подтверждения от приемника или передатчика.

            Резервирование полосы пропускания так же может быть прекращено после передачи приемником или передатчиком запроса на отмену соединения.

Качество услуг.   Качество услуг (QoS) - это ключевая фраза для обозначения сетей передачи данных без потери ячеек с предсказуемой задержкой из конца в конец и доставкой в реальном времени после установления соединения. Высококачественное мультимедиа в сети как в реальном времени, так и при воспроизведении аудио- и видеофайлов с сервера предполагает наличие сети с обеспечением качества услуг. Такие протоколы, как ATM, разрабатывались специально для предоставления нескольких уровней услуг. Обеспечение качества услуг в случае IP возможно только при использовании специальных протоколов, таких как RSVP, для резервирования пропускной способности на промежуточных устройствах (маршрутизаторах).

Компьютерная телефония.   Термин “компьютерная телефония” (Computer-Telephony Integration, CTI) относится к реализации традиционных аудио- (иногда и видео-) сервисов в сети передачи данных. Системы компьютерной телефонии могут быть реализованы как в сетях с гарантированной пропускной способностью (типа ATM), так и в сетях передачи кадров (типа Ethernet или frame relay).

CIF. Общий промежуточный формат (Common Intermediate Format) с разрешением 352 пиксела по горизонтали на 288 пикселов по вертикали является наиболее популярным форматом изображений в видеоконференциях. При меньшей пропускной способности видеосистемы используют, как правило, либо QCIF (Quarter CIF) с разрешением 176х144 пиксела, либо SQCIF (Sub-Quarter CIF) с разрешением 128х96 пикселов. Видео с высокой пропускной способностью описывается форматом 4CIF (704х576 пикселов) или 16CIF (1408х1152 пиксела).

G.711.   Один из основных стандартов ITU-T для аудиокодеков (кодировщиков-декодировщиков голоса и музыки). G.711 является частью более общих мультимедийных стандартов, таких как H.320 и H.323, кроме того, он используется в компьютерной телефонии и сам по себе. G.711 определяет аудиосигнал с шириной полосы 3,4 КГц (иными словами, обычный аналоговый голосовой сигнал) по информационным каналам в 64 Кбит/с. Стандарт G.722 описывает аудиопоток с шириной полосы 7,0 КГц по каналу в 64 Кбит/с, а стандарт G.728 - аудиопоток с шириной полосы 3,4 КГц по каналу в 16 Кбит/с. Стандарт G.723 определяет передачу компьютерной аудиоинформации по узкополостным телефонным линиям. Он описывает уплотненный сигнал в 3,4 КГц для обычных телефонных линий и используется в мультимедийном стандарте H.324.

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

H.261.   Стандарт ITU-T на кодек со сжатием видео. Поддерживаемый H.320, H.323 и H.324, H.261 совместим с форматами изображений CIF и QCIF. H.261 разрабатывался для  спользования с ISDN и допускает скорости передачи данных, кратные 64 Кбит/с. Новый стандарт H.263 (поддерживаемый H.324) повышает эффективность H.261 и совместим с изображениями в форматах SQCIF, 4CIF, 16CIF.

H.320.   Один из основных стандартов ITU-T для мультимедиа в реальном времени. H.320 - это стандарт для видеоконференций в узкополосных глобальных сетях с коммутацией каналов, таких как ISDN. Он включает спецификации для данных (T.120), голоса (G.711 и G.728), видео (H.261) и шифрования (H.233 и H.234). H.323 представляет собой усовершенствованный стандарт H.320 для основных сетей с коммутацией пакетов. Родственные стандарты для мультимедиа реального времени, не рассматриваемые отдельно в этом словаре, включают H.321 для широкополосного ISDN и ATM, H.322 для сетей коммутации пакетов с гарантированной полосой пропускания и H.310 для мультимедиа высокого разрешения поверх ATM.

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

Здесь приходит на помощь стандарт Н.323, определяющий передачу видео и аудио по сетям с негарантированным качеством услуг, таким как Ethernet и IP.Н.323 описывает несколько элементов, в том числе аудио- и видеокодеки (кодеры/декодеры), коммуникационные протоколы и синхронизацию пакетов. Первоначально стандарт разрабатывался для рынка видеоконференций в качестве альтернативы сеансов по ISDN, но теперь сообщество IP-телефонии адаптировало стандарт для своих собственных нужд.

Но из-за того, что Н.323 разрабатывался для видеоконференций, далеко не всякий шлюз и клиент IP-телефонии поддерживает стандарт. Тем не менее эта ситуация постепенно меняется, так как число производителей, высказывающихся в пользу стандартов и работающих над их оптимизацией для IP-телефонии, неуклонно растет. Среди компаний, заявивших о поддержке Н.323, - VocalTec, Clarent, Dialogic, Array Telecom, Micom, Microsoft, Intel, Brooktrout. В сентябре 1997 года на конференции "Голос по сети" в Бостоне производители из всех областей рынка IP-телефонии

приняли участие в крупнейшей публичной демонстрации интероперабельности Н.323.

H.324. Стандарт ITU-T для передачи мультимедиа в реальном времени по обычным телефонным линиям с помощью модемов V.34 на 28,8 Кбит/с или более быстрых. Подобно H.320, H.324 включает стандарт T.120 для разделения данных, сжатие видео по стандарту H.261, а также стандарты шифрования H.233 и H.234. В отличие от H.320, H.324 использует аудиостандарт G.723.

MMX.   По утверждению Intel, акроним “MMX” не имеет какого-либо конкретного значения, но обычно он расшифровывается как “Мультимедийные расширения”. Более конкретно MMX реализуется как набор новых команд для микропроцессоров Pentium с MMX и Pentium II. Однако MMX занимается не только Intel: так, например, компания Advanced Micro Devices, конкурирующий производитель процессоров, выпустила новое MMX-совместимое семейство процессоров. Многие новые мультимедийные продукты под Windows для компьютерной телефонии и видеоконференций пишутся с учетом преимуществ новых команд MMX.

RTP.   Транспортный протокол реального времени - это стандарт IETF для передачи данных, таких как голос или видео, в реальном времени по пакетной сети, не гарантирующей качества услуг. Связанный с ним стандарт - протокол управления передачей в реальном времени (Real-Time Transport Control Protocol, RTCP) - обеспечиваетобратную связь между двумя устройствами или группой. Такие мультимедийные стандарты ITU-T для сетей без обеспечения качества услуг, как H.323 и H.324, опираются на RTP/RTCP.

T.120.   Этот стандарт ITU-T касается разделения мультимедийных данных по сети в реальном времени. Он служит базисом для таких приложений, как совместная работа над проектами при двусторонних или многосторонних сеансах. T.120 является составной частью некоторых стандартов видеоконференций, например H.320, H.323 и H.324.

РЕЗЮМЕ.

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


Страницы: 1, 2


Новости


Быстрый поиск

Группа вКонтакте: новости

Пока нет

Новости в Twitter и Facebook

                   

Новости

Обратная связь

Поиск
Обратная связь
Реклама и размещение статей на сайте
© 2010.