Некоторые рекомендации по созданию сетей ATM с видео Существует несколько вопросов, которые требуют своего рассмотрения при разработке инфраструктуры для видеоприложений. Дело в том, что нельзя просто взять работающую сеть с передачей видео и слепо ее скопировать. Если так поступить, то вовсе не обязательно, что в получившейся копии сети видео будет передаваться с таким же качеством. Из-за множества нюансов работы видеоприложений в сетях любые две сети отличаются с этой точки зрения, что делает простое копирование невозможным. Кроме того, на процесс передачи видеоинформации влияют отличия в реализации локальных и глобальных сетей. Однако можно привести некоторые общие рекомендации по созданию сети с поддержкой передачи видеоинформации.
С точки зрения сети, видеоприложения можно разделить по следующим категориям:
q Пакетное видео, которое работает поверх традиционных сетей на канальном или сетевом уровнях, и которое может передаваться через сеть ATM с помощью технологий эмуляции локальных сетей или МРОА;
q Видео с постоянной скоростью, которое работает поверх каналов со скоростью N464 Кбит/с или в каналах ISDN и будет передаваться поверх ATM с использованием технологии эмуляции каналов. Такие приложения задействуют коммутаторы ATM, мультиплексоры и существующее оборудование выделенных каналов связи;
q Пакетное видео, которое передается поверх ATM, используя уровень схождения «MPEG-2 поверх ATM». Стандарты, которые позволят осуществлять такую передачу, находятся в стадии разработки и не будут широко распространены еще несколько лет.
Когда видеоприложения наберут достаточный вес и «обрастут» стандартами, а на конечных станциях будет установлена полная совокупность поддерживающих их приложений, сетевая инфраструктура станет определяющей для широкого внедрения видео. Организации в этом случае могут полностью полагаться на свою сетевую инфраструктуру при выборе различных видеоприложений для внедрения. Главенство сетевой инфраструктуры позволит очень долго обновлять видеоприложения без кардинальной замены оборудования. В табл. 18.9 перечислены рекомендации, которым можно следовать при внедрении видеоприложений.
Видеоприложения могут использовать метод пакетной передачи (что означает взрывную или переменную скорость) или передавать видеоинформацию с постоянной скоростью. Такие приложения разрабатываются для работы поверх традиционных локальных сетей. Приложения используют определенные алгоритмы, которые сжимают традиционные пакеты, будь то дейтаграммы протокола IP (или их эквиваленты) или кадры сети Ethernet.
Так как пакетное видео функционирует поверх инфраструктуры локальной сети, то оно будет работать еще лучше, если сеть поддерживает качество обслуживания. Кроме того, когда видеоприложение, изначально ориентированное для работы поверх локальных сетей, будет функционировать поверх сети ATM, то необходимо использовать технологии LANE и МРОА.
Когда пакетное видео работает напрямую через сеть ATM, между видеопотоком и уровнем адаптации ATM должен существовать уровень схождения. В качестве уровня адаптации вероятнее всего использование AAL5, что определено последними разработками Форума ATM. Эта работа находится в своей ранней стадии, так же, как и разработка стандартного алгоритма сжатия двунаправленного высококачественного видео в сети с узкой полосой пропускания (формат MPEG-4). Форум ATM не рассматривает возможность работы MPEG-4 поверх ATM. Вместо этого он сосредоточил свои усилия на укреплении позиций стандарта MPEG-2, который хорошо подходит для таких приложений, как широковещательное видео.
Передача сжатой видеоинформации может носить взрывной характер. В том случае, когда видео передается через каналы N 64 Кбит/с глобальных сетей, «взрывной» поток сжатого видео должен преобразовываться в поток с постоянной скоростью. Это необходимо для удовлетворения требований по передаче через цифровые каналы. Традиционное оборудование для проведения видеоконференций, например, выпускаемое фирмой PictureTel, использует некоторые варианты набора протоколов Н.320/Н.261. Последний предусматривает использование буферов для гарантии того, что информация будут всегда посылаться с определенной периодичностью, вне зависимости от исходной структуры трафика.
Такой видеотрафик с постоянной скоростью при передаче через сеть ATM требует эмуляции каналов, при которой ATM эмулирует традиционные каналы N 64 Кбит/с или каналы ISDN таким образом, чтобы это устраивало оборудование, поддерживающее стандарт Н.320.
Так как в эталонной модели OSI сетевой уровень скрывает транспортные протоколы и приложения от протоколов канального уровня, то видеоприложения, которые будут взаимодействовать через гетерогенные сети, могут использовать либо сетевой уровень, например IP, либо МАС-подуровень канального уровня. Хотя стоит отметить, что использование МАС-подуровня без сетевого уровня приводит к традиционным проблемам, а именно – к плоской сети.
Видео может передаваться через различные уровни в стеках протоколов. Как показано на рис. 18.3, различные кодеки могут использовать различные методы для взаимодействия между собой. Ясно, что выбор приложения будет определять тип сети и наоборот.
Если кодек при своей работе регламентирует использование сетевого уровня, он может передавать информацию группе через протокол IP, а его трафик может коммутироваться с помощью технологии МРОА. Если кодек пропускает сетевой уровень, а вместо этого упаковывает видеоинформацию в кадры Ethernet или Token Ring, то возможности маршрутизации будут утрачены, хотя средства групповой доставки по-прежнему останутся (на уровне Ethernet в локальной сети или через технологию LANE в ATM).
Аналогично, видео, соответствующее стандарту Н.320, которое должно передаваться через цифровые каналы, может использовать эмуляцию таких каналов в сети ATM. При этом маршрутизация будет недоступна. Такое соединение с передачей видео при проведении конференций типа точка-точка будет обычно заканчиваться на другом устройстве, поддерживающем Н.320.
Для пакетного видео в локальной сети высокопроизводительные коммутаторы и маршрутизаторы являются хорошим выбором для построения сетевой инфраструктуры. С точки зрения производительности, большая сегментированность локальной сети (то есть меньшее число доменов коллизий) повышает эффективность работы видеоприложений. Желательно, чтобы маршрутизаторы поддерживали протоколы групповой маршрутизации и протокол резервирования ресурсов.
Когда сеть передает большой объем видеоинформации, требуется большая пропускная способность в каналах до серверов и в магистрали сети. Поэтому для повышения эффективности видеоприложений эти каналы можно построить с использованием технологии ATM (рис. ,18.4).
В промежуточном варианте можно использовать коммутацию в локальной сети и технологию LANE, в которых каждый конечный пользователь получает как бы выделенный канал Ethernet для гарантированной доставки видеоинформации от сервера. При внедрении все большего числа разнообразного оборудования для проведения видеоконференций большинство пользователей будет подключаться к локальным сетям, особенно с учетом того, что коммутаторы становятся все более доступными. По данным некоторых исследователей, порядка 75 % оборудования для проведения видеоконференций будет поддерживать пакетное видео и будет иметь возможность подключаться к локальным сетям.
Передача голоса
Передачу голоса по сети, которая рассчитана на пересылку данных, можно осуществить, используя функции одного из двух уровней модели OSI: канального или сетевого. В первом случае используются сети ATM или Frame Relay. Во втором – задействуется протокол IP. В обоих случаях голосовой сигнал необходимо предварительно оцифровать и сформировать в пакеты, вид которых соответствует используемой технологии. После этого пакеты могут посылаться в сеть.
Для поддержки голосового взаимодействия двух абонентов требуется канал с пропускной способностью 64 Кбит/с. Существуют технологии, позволяющие значительно снизить это число и предъявляющие, тем самым, менее жесткие требования к пропускной способности. Это достигается за счет сжатия голосовой информации и эффективного использования пауз в разговоре абонентов. Специализированные процессоры для обработки цифровых сигналов обеспечивают сжатие оцифрованного голоса до 32, 16 и 8 Кбит/с. При выделении пауз и их заполнении передачей другой информации можно значительно повысить эффективную пропускную способность.
Для передачи голосового сигнала через сеть необходимо решить две основные проблемы: задержки в сети и потери пакетов. Исследования показывают, что при задержках до 300 мс качество передачи голосового сигнала вполне приемлемо. Существуют более жесткие рекомендации, регламентирующие максимальную величину задержки при передаче речи в 150 мс. При превышении данного порога качество начинает резко ухудшаться. Задержка голосового сигнала может происходить на любом этапе формирования пакета, его движения по сети и преобразования в исходную форму. Задержка также происходит при импульсно-кодовой модуляции, сжатии сигнала, прохождении по сети и декодировании. Кроме того, задержка возникает из-за некорректного распределения полосы пропускания канала связи между голосовым трафиком и трафиком данных.
Для управления задержками применяются специальные протоколы:
q RTP (Real-Time Transport Protocol) – призван заменить протоколы TCP и UDP при передаче трафика в реальном масштабе времени. Этот протокол переносит в своем заголовке временные отметки, необходимые для успешного восстановления аудио- и видеоинформации, и данные о типе ее кодирования;
q RTCP (Real-Time Transport Control Protocol)– предоставляет приложениям механизм реагирования на изменения в сети. Например, получив информацию о повышении интенсивности трафика в сети и уменьшении выделенной этому приложению полосы пропускания, приложение может принять меры и умерить свои требования к полосе пропускания за счет, например, некоторой потери качества. После снижения нагрузки в сети приложение может восстановить исходную полосу пропускания и продолжить работу с тем качеством, которое оно предоставляло вначале.
q RSVP – позволяет резервировать пропускную способность, необходимую для передачи пакетов с требуемым качеством.
Проблема с потерей пакетов решается путем дублирования потерянных или искаженных пакетов. Но для этого придется использовать дополнительные ресурсы сети. Существует более экономный способ решения этой проблемы: придать голосовому трафику более высокий приоритет по сравнению с трафиком данных. Для этого чаще всего используется протокол UDP, так как он не предусматривает подтверждения получения каждого посланного пакета и поэтому наиболее оптимально подходит для передачи голоса. Использование для этих целей протокола TCP приводит к тому, что пакеты нумеруются в порядке их отправления, и затем отправитель ожидает подтверждения получения каждого пакета. Если рассматривать передачу данных, то такая схема имеет смысл, так как там во главу угла ставится целостность информации, но при транспортировке голосовой информации это может приводить к нежелательным эффектам.
Трудности при реализации передачи голосового трафика могут возникнуть из-за нестыковки оборудования и программных средств. Связь может быть реализована только в том случае, если у обоих абонентов установлено идентичное оборудование.
Широкое использование технологии Frame Relay для передачи голосового трафика объясняется небольшими потерями (3-4 %) при упаковке голосового пакета в кадр Frame Relay и возможностью выделения гарантированной полосы пропускания CIR (Committed Information Rate). Значительную роль в повышении популярности передачи голоса по сети Frame Relay играет достаточно большая предсказуемость поведения сети в любых ситуациях и, самое главное, небольшие задержки при передаче информации. Очень важным обстоятельством, говорящим в пользу использования сети Frame Relay, является ее адаптируемость к существующим технологиям глобальных сетей. Под этим понимается возможность строить сети не только на базе выделенных каналов связи, но и на базе существующих сетей. Однако существуют и достаточно непростые вопросы, которые необходимо решать для обеспечения качественного голосового обмена. К ним относятся проблемы, связанные с эффективным использованием полосы пропускания и заторами при передаче кадров.
Для определения стандартной реализации средств передачи голоса по IP-сетям в начале 1996 года был образован Форум «Голос по IP» («Voice over IP», VOIP). Форум поддерживает стандарт Н.323, который определяет все аспекты передачи мультимедийного трафика по IP-сетям.
С точки зрения организаций, ощутимым преимуществом передачи голоса с помощью протокола IP может стать некоторое сокращение накладных расходов, так как существующая сеть передачи данных при реализации передачи голоса становится альтернативой общедоступной телефонной сети. Многие организации уже имеют распределенные сети на базе протокола IP. Самое главное, что сейчас вопросу передачи голоса через IP-сети уделяется огромное внимание – и в печати, и производителями, и заказчиками. Это связано с тем, что протокол IP в настоящее время является основным протоколом, на котором базируются корпоративные и глобальные сети. В ближайшем будущем этот протокол вряд ли уступит свое лидирующее положение. На основании этих аргументов производители ориентируются именно на протокол IP в своих последних разработках, направленных на повышение производительности сетей (примером может служить разработка и принятие стандарта на технологию МРОА).
Одним из технических решений, используемых для передачи голоса по IP-сетям, является применение специального шлюза, подключаемого к центральному серверу локальной сети. При этом такой шлюз делает функции передачи голоса прозрачными для пользователя, использующего обычные телефонные и факсовые аппараты. При передаче голоса поверх протокола IP возникают те же проблемы, что и в случае использования сети Frame Relay. Основные неприятности доставляет задержка голосовых пактов. Однако ситуация несколько усугубляется тем, что в протоколе IP эти задержки могут носить непредсказуемый характер, и практически отсутствует возможность контролировать их.
В июле 1997 года Форум ATM одобрил спецификацию «Голос и телефония по ATM до настольных систем» («Voice and Telephony over ATM, VTOA, to the Desktop Specification»). Эта спецификация поддерживает передачу голосового трафика с помощью протоколов ATM. При этом VTOA способна обеспечить передачу голосового трафика, опираясь на протоколы ATM, подобно тому, как это делают технологии МРОА и LANE.
Комитет по голосу и телефонии поверх ATM – Voice and Telephony Over ATM (VTOA) – Форума ATM выпустил ряд документов, посвященных следующим вопросам: способам передачи цифровых данных со скоростями, кратными скорости основного цифрового голосового канала DSO, в ячейках ATM (CES – служба эмуляции выделенных каналов) и преобразованию систем сигнализации телефонии и протоколов ATM (IWF – межсетевая функция). Служба CES позволяет создавать цифровые каналы связи через сеть ATM между двумя точками так же, как это делалось в сетях SDH, но, в отличие от SDH, полоса пропускания такого канала в ATM может быть любой – от 64 Кбит/с до величины, лимитированной только пропускной способностью линии связи. Это делает возможным использование ATM в качестве транспортной среды для телефонии.
Технология ATM способна обеспечить сверхмалые, по сравнению с протоколом IP, задержки сигналов при передаче. Величина задержки может быть меньше 20 мс. При этом следует иметь в виду, что такая задержка при передаче голосового трафика подразумевает, что виртуальное соединение (будь то постоянное или коммутируемое) уже установлено. Но если принимать во внимание и время, необходимое на установление виртуального соединения (особенно коммутируемого), то здесь преимущества технологии ATM выглядят менее впечатляюще.
Технология ATM обладает полным набором средств для реализации голосового взаимодействия. Кроме использования постоянных виртуальных соединений для организации канала связи, ATM может создавать коммутируемые соединения между вызывающей телефонной станцией и абонентом. Для этого ATM имеет собственные системы адресации и сигнализации. Наличие этих механизмов позволяет интегрировать ATM в состав корпоративной телефонной сети.
Основной задачей межсетевой функции (Internetworking Function, IWF) является организация взаимодействия систем сигнализации телефонных сетей и устройств ATM. Эта межсетевая функция может быть реализована как на коммутаторе ATM, так и на УАТС (учережденческих автоматических телефонных станциях). На рис. 18.5 показаны упрощенные функциональные схемы этих двух вариантов. В первом случае на коммутаторе должна быть реализована служба CES.
Голос по сети ATM можно передавать с использованием двух классов сервисов: службы CBR и службы VBR. Служба VBR используется в случаях, когда выдвигаются жесткие требования к занимаемой полосе пропускания. В менее ответственных случаях может быть использована служба CBR. Служба CBR при своей работе использует уровень адаптации AAL1 (структурированный и неструктурированный режимы). Уровень адаптации AAL5 используется со службой CBR и является наиболее приемлемым и дешевым способом реализации «голоса по ATM» непосредственно от рабочего места. К сожалению, существенным недостатком является то, что эти два метода несовместимы.
Вышеизложенные теоретические схемы были реализованы на практике: производители коммутаторов стали выпускать устройства, имеющие интерфейсные модули эмуляции телефонных каналов, а производители УАТС разработали и стали выпускать телефонные станции, способные взаимодействовать с магистралью ATM.
Существует рекомендация, которая определяет, что связь между коммутатором ATM с эмуляцией каналов и УАТС должна осуществляться цифровым потоком со скоростью 2 Мбит/с. В этом случае при взаимодействии нескольких телефонных станций через сеть ATM между ними могут быть образованы виртуальные соединения любой пропускной способности (точнее, любой кратной пропускной способности основного канала). Важным преимуществом такой схемы является возможность прямого взаимодействия двух телефонных станций без промежуточных систем. Кроме снижения требований к производительности телефонной станции такая схема значительно повышает надежность всей сети в целом. Использование коммутируемых виртуальные соединений дает дополнительные возможности, рассмотренные нами выше.
Компания Lucent Technologies создала граничные и территориальные коммутаторы с интеграцией голоса, видео и данных. Компания Cisco Systems в 1997 году выпустила модуль эмуляции каналов Т1/Е1 для своего семейства маршрутизаторов 7200 и коммутаторов LightStream 1010 ATM.
Если телефонная станция имеет модуль связи с магистралью ATM, то можно получить дополнительные возможности. Подключения УАТС к коммутатору ATM производится по интерфейсу STM-1 (155 Мбит/с) с реализацией всех функций ATM на этом интерфейсе. В данном случае одна из систем адресации ATM использует телефонные номера ISDN как часть адреса. В этом случае из магистрали ATM становятся доступны терминалы, подключенные к телефонной станции.
В настоящее время разработано и реализовано достаточно много интересных схем подключения телефонных станций к магистрали ATM. Очень важно, что все разработчики придерживаются вполне определенного набора стандартов. Это означает, что сближение и интеграция функций ATM и УАТС будут продолжаться. При этом будут реализовываться все новые возможности.
Часть V Приложения
|