Технология SecureFast фирмы Cabletron

Технология SecureFast Virtual Networing (SFVN) фирмы Cabletron основана на комбинации коммутации и маршрутизации. Коммутация в коммутаторах Cabletron SmartSwitch обеспечивается встроенной функцией коммутации третьего уровня, а маршрутизация поддерживается специальным сервером маршрутизации.

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

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

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

При получении широковещательных пакетов с объявлениями коммутатор будет передавать их только тем устройствам, которые нуждаются в них. Напри­мер, сообщения протокола маршрутизации RIP IP будут получать только марш­рутизаторы.

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

Технология SFVN имеет много общего с технологией Multiprotocol Over ATM (MPOA), которая рассматривается далее. Обе технологии используют сер­вер маршрутизации и устанавливают логическое соединение между абонентами. Кроме того, они не зависят от используемого сетевого протокола.

Недавно фирма Cabletron объявила о своем намерении согласовать с фирмой Ipsilon технологии SFVN и IP Switching. Если такое партнерство станет реаль­ностью, технология SFVN будет использоваться в промышленных сетях, а тех­нология IP Switching — для организации связи отдельных SFVN-сетей.

Технология Multiprotocol Switched Services фирмы IBM

Технология Multiprotocol Switched Services (MSS) реализует одно из направле­ний, продвигаемых фирмой IBM для развития ATM, и ориентирована на приме­нение в центре сети. Технология MSS как бы выносит функции маршрутизации на края сети и опирается на два основных компонента: MSS-сервер и MSS-клиент.

MSS-сервер действует как сервер маршрутизации и отвечает за вычисление маршрута. Кроме того, он выполняет функции сервера эмуляции LANE и под­держивает виртуальные сети. MSS-сервер может иметь две реализации: централизованную, при которой он устанавливается на одном коммутаторе ATM, или распределенную, при которой сервер устанавливается на нескольких коммутато­рах. MSS-сервер поддерживает следующие стандарты: NHRP, LANE и МРОА.

MSS-клиенты могут располагаться на граничных коммутаторах ATM, на рабочих станциях или на серверах, напрямую подключаемых к сети ATM. MSS-клиент выполняет передачу кадров и фильтрацию, предоставляет функцио­нальные возможности технологии LANE обычным клиентам и кэширует информацию о получателе, предоставленную MSS-сервером.

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

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

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

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

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

Однако до полного перехода к этой технологии пройдет немало времени, в течение которого ATM и существующие сети (такие как Ethernet, Token Ring и т. д.) будут сосуществовать вместе. Для того чтобы воспользоваться и преимуществами ATM, и распространенностью существующих сетей, видеоприложения должны поддерживать обе технологии, которые, в свою очередь, должны интегрироваться друг с другом.

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

На смену стандарту Н.320 пришел стандарт Н.323, который описывает компоненты и оборудование, поддерживающие мультимедийный трафик в локальных сетях, таких как Ethernet, Token Ring и т. д. Стандарт Н.323, обладая преемственностью по отношению к Н.320, имеет несколько очень важных преимуществ. К ним можно отнести широкое использование существующей сетевой инфраструктуры и более дешевую реализацию. Кроме того, понятие видеоконференции расширяется возможностью совместной работы над документами и проведения аудиоконференций. Стандарт Н.323 определяет режим сжатия и передачи аудио- и видеоинформации в реальном масштабе времени и управляющие протоколы. Важной чертой этого стандарта является то, что в нем предусмотрены и описаны методы взаимодействия с оборудованием, его не поддерживающим. Связь с доминирующим сегодня протоколом IP открывает для этого стандарта достаточно широкие перспективы.

Однако можно отметить и недостатки этого стандарта. Его транспортный механизм реализован на протоколе UDP. А это значит, что Н.323 не обеспечивает целостности видеосигналов при передаче. Стандарт определяет механизм отправки информации, но не определены механизмы реагирования на ее «пропажу». То есть, сам стандарт Н.323 не предусматривает обеспечения качества обслуживания, а полагается на предоставление необходимого качества от сети.

Недостаток стандарта Н.323, касающийся качества обслуживания, восполняют новые протоколы. К ним можно отнести протокол RSVP и его прародителя протокол ST2 (Stream Protocol). Они работают в IP-сетях и обеспечивают резервирование ресурсов и предоставление требуемого качества обслуживания. Недостатком протокола ST2 является довольно высокая стоимость его реализации. В этой связи и был создан коммерческий вариант этого протокола – протокол RSVP.

Одновременно с разработкой и внедрением протоколов, реализующих технологию качества обслуживания, был разработан новый транспортный протокол, обеспечивающий передачу мультимедийного трафика. Этот протокол, называемый RTP, обеспечивает передачу данных между конечными станциями в сети. Протокол RTP применяется в стандарте Н.323 и работает поверх UDP. Такое совместное использование транспортных протоколов позволяет, в частности, обеспечить последовательное поступление данных. Протокол RTP пришел на смену известному протоколу TCP. При всех положительных качествах последнего (гарантия доставки и правильной последовательности поступления пакетов, а также ряда других) суммарные задержки трафика делают его непригодным для передачи видеоинформации. Важной особенностью протокола RTP является его способность распознавать содержимое пакетов (например, различать спецификации кодека) и обнаруживать их потерю. Кроме того, задержки, вносимые механизмами этого протокола, приемлемы для мультимедийного трафика. Совместное использование протоколов RTP и RSVP позволяет резко расширить круг пользователей сетевого видео в реальном масштабе времени.

В дополнение к протоколу RTP разработан протокол RTCP (Real Time Transport Control Protocol, протокол управления транспортом в реальном времени), работающий совместно с TCP по управлению потоками данных. При этом протокол RTCP обеспечивает обратную связь, которая позволяет приложениям «узнавать» текущее состояние сети и учитывать его в своей работе.

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

Спецификация Н.323 Multipoint Control Unit (MCU) описывает процесс объединения нескольких пользователей Н.323 в конференцию с несколькими конечными пунктами. Однако можно сказать, что на сегодняшний день внедрение стандарта Н.323 происходит достаточно медленными темпами. В глобальных сетях его нельзя использовать из-за больших задержек. С другой стороны, существуют серьезные технические сложности при его внедрении в корпоративные сети. Удешевление каналов связи ISDN приводит к тому, что стандарт Н.320 как бы рождается заново и получает шансы на совершенствование и дальнейшее развитие.

Передача видеоинформации

Видеоинформация может передаваться по сети без сжатия или со сжатием. В последнем случае говорят о так называемом «сжатом видео». Для передачи видео без сжатия определен ряд форматов, требующих определенной пропускной способности. При этом в зависимости от установленного разрешения кадр может заполнять как весь экран, так и его часть (табл. 18.1). При передаче используется общий промежуточный формат CIF (Common Intermediate Format), который также называют FCIF (Full CIF). Стандартными производными от последнего формата являются форматы QCIF (Quarter CIF) и SQSIF (Subquarter CIF).

Таблица 18.1. Требования к пропускной способности (видео без сжатия)

Примечание: все данные приведены в предположении глубины цвета в 16 бит.

В настоящее время передача видеоинформации без сжатия используется довольно редко. Это связано с широкой полосой пропускания, которая необходима для такой передачи. Несжатая видеоинформация обычно используется в сетях тех организаций, которые не испытывают проблем с предоставлением достаточной пропускной способности. Различные форматы изображений (в зависимости от размера картинки, ее разрешения и количества кадров, передаваемых в секунду) требуют различной пропускной способности. В табл. 18.2 описаны требования к пропускной способности для различных форматов изображения, используемых как в мире персональных компьютеров (предназначенных для видеостандартов EGA, VGA и т. д.), так и тех, что применяются в телевидении (например, PAL и SECAM).

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

Таблица 18.2. Требования к пропускной способности (полноэкранное видео без сжатия)

Существует несколько форматов сжатия видеоинформации, одни из которых являются фирменными решениями, а другие – открытыми стандартами. Протоколы, реализующие эти форматы, включают методы оцифровки изображения (преобразования из аналогового сигнала в цифровой и обратно), а также компрессии и декомпрессии. При этом сжатие может производиться как внутри каждого кадра (так называемое пространственное сжатие), так и между кадрами. И то, и другое осуществляется с помощью специальных схем. Эти протоколы обеспечивают совместимость с протоколами низших уровней и проведение мультиплексирования различных потоков аудио- и видеоинформации от отдельных отправителей с последующим демультиплексированием на другом конце. Например, в наборе протоколов Н.320, используемых для видеоконференций, протокол Н.221 служит в качестве надстройки над протоколами низших уровней и отвечает за мультиплексирование, в то время как протокол Н.261 – это протокол для компрессии и декомпрессии видео.

В 1988 году была создана группа MPEG, основной задачей которой была разработка стандартов по сжатию аудио- и видеоинформации. В разработанных стандартах определялся входной битовый поток с неявным описанием алгоритмов кодирования и декодирования. В результате производители получили возможность, с одной стороны, реализовывать свои фирменные алгоритмы кодирования и декодирования, с другой стороны, им была обеспечена совместимость с промышленным стандартом. В сентябре 1990 года был представлен предварительный стандарт кодирования MPEG-1, а в январе 1992 года работа над ним была завершена. После этого был разработан и принят стандарт MPEG-2, который определяет потоки данных со скоростью от 3 до 10 Мбит/с.

Видеоинформация, сжатая в соответствии с форматами MPEG-1 и MPEG-2, различается по своему качеству. Хотя алгоритм MPEG-1 может работать с разрешениями до 720х480, обычно, видео кодируется при значительно меньшем разрешении (это делается, чтобы уменьшить интенсивность потока данных), что приводит к ухудшению качества изображения. MPEG-1 обычно ассоциируется с форматом SIF (разрешение 352х240), что аналогично качеству VHS (то есть бытового видеомагнитофона).

Формат MPEG-2 позволяет поддерживать более высокие разрешения (в том числе, 720х480). При этом скорость передачи видеоинформации примерно в четыре раза больше скорости передачи, которую способен поддерживать MPEG-1, что позволяет передавать с помощью формата MPEG-2 полноэкранные фильмы с телевизионным качеством. Важной особенностью формата MPEG-2 является наличие в нем расширений, которые служат для разделения видео на несколько независимо кодируемых потоков, что позволяет создавать независимые потоки с определенной интенсивностью в рамках одного видеосигнала.

В отличие от алгоритмов Motion-JPEG (которые кодируют кадры независимо, при этом каждый кадр кодируется по технологии JPEG) технология MPEG использует поточное сжатие видеоинформации, при котором происходит обработка не каждого кадра в отдельности, а производится анализ изменений отдельных фрагментов изображений и кодируется именно изменение сигнала, а не сам сигнал. При этом также происходит устранение избыточности. Так как в большинстве случаев фон изображения остается достаточно долго без изменений, а действие происходит только на переднем плане, то алгоритм MPEG начинает сжатие с создания исходного кадра. Эти кадры являются отправными для воссоздания фона на принимающей стороне; они размещаются последовательно через каждые 10-15 кадров, несущих «картинку» переднего плана. Только некоторые фрагменты изображений, которые находятся между ними, претерпевают изменения, и именно эта разница сохраняется при сжатии.

Одним из последних кодеков для видео в реальном времени является Real-Video. Компания Microsoft анонсировала кодек MPEG-4, предназначенный для видео в реальном времени. С другой стороны, кодек Н.263 уже поддерживается несколькими системами для проведения видеоконференций.

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

Таблица 18.3. Требования к пропускной способности (сжатое видео)

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

Таблица 18.4. Требования к пропускной способности видео различного качества

Как видно, изображение с очень хорошим качеством (студийным) требует от сети пропускной способности менее 10 Мбит/с, что вполне может предоставить коммутируемое подключение Ethernet. Однако требования к пропускной способности возрастают, если по тем или иным причинам видеоинформацию сжимать нельзя. В некоторых приложениях (например, в медицине) даже небольшая потеря качества, вызываемая сжатием, недопустима. С другой стороны, если через одну и ту же инфраструктуру требуется передавать несколько видеопотоков, то пропускной способности в 10 Мбит/с, предоставляемой коммутируемым Ethernet, все равно становится недостаточно.

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

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

Записанная видеоинформация может, грубо говоря, рассматриваться как большой массив данных. Для передачи этого массива данных пропускная способность, как правило, не резервируется, и он передается при доступных сетевых ресурсах. Такой массив данных может быть записан на CD-диски и передан потребителям видеоинформации по сети в необходимое время, или тогда, когда нагрузка на сеть минимальна – это пример подхода к передаче видео, как к передаче данных.

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

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

Хотя сегодня аудиоинформация, видеоинформация и данные разделены, в будущем тенденция к интеграции различных услуг в одной сети усилится. Наиболее вероятным сценарием объединения будет следующий: на первом этапе произойдет интеграция передачи видеоинформации с передачей данных. После всесторонней эксплутационной «доводки» этой интегрированной технологии можно будет, опираясь на новые стандарты, приниматься за дальнейшее развитие системы передачи голоса по сети. А учитывая тенденцию объединения локальных сетей с сетями ATM, наметившийся симбиоз имеет все шансы стать широко доступным и повсеместно распространенным.

Видео в реальном времени и записанное видео предъявляют к сети определенные требования, необходимые, чтобы гарантировать высокое качество. К ним относятся: достаточная полоса пропускания, низкая задержка, небольшое дрожание и эффективный механизм групповой доставки. Достаточность полосы пропускания определяется объемом передаваемой информации и применяемыми методами сжатия. Низкая задержка необходима для организации сеансов связи «в прямом эфире», когда пользователи общаются непосредственно друг с другом в реальном времени. Устранение дрожания требуется приложениям, обеспечивающим однонаправленную передачу, – это необходимо для избежания «скольжения» кадров или потери синхронизации между звуком и изображением. И, наконец, групповая доставка нужна для того, чтобы видеоинформация не дублировалась несколько раз для нескольких пользователей.

Следует отметить, что если отправитель и получатель являются членами одной физической сети, процесс передачи и приема групповых сообщений на канальном уровне достаточно прост. Отправитель указывает IP-адрес группы получателей, а сетевая плата выполняет процедуру трансляции этого адреса в соответствующий групповой Ethernet-адрес и посылает кадр. Если отправитель и получатель находятся в разных подсетях, которые, однако, связаны маршрутизаторами, то доставка пакетов затруднена. В этом случае маршрутизаторы в сети должны поддерживать один из групповых протоколов маршрутизации (DVMRP, MOSPF, PIM). Этот протокол построит дерево доставки и передаст групповой трафик.

В основном, при использовании стандартных методов сжатия, таких как MPEG-2, видеоприложения предъявляют следующие конкретные требования к пропускной способности и задержкам (рис. 18.1).

Рис. 18.1. Требования к задержке различных приложений

Задержка критична в ситуациях, когда происходит двунаправленное общение, так как в этом случае задержка в ответе одного из абонентов приводит к очевидным неудобствам в общении (что можно довольно часто наблюдать в наших новостях, когда диктор в студии в Москве общается с корреспондентом, находящимся где-нибудь в Вашингтоне). Один из абонентов должен ожидать до тех пор, пока удаленный абонент не закончит всю фразу целиком. В противном случае, из-за задержек, фраза может быть понята неправильно. Такая проблема достаточно ощутима, например, при использовании приложений стандарта Н.320. Хотя считается, что задержка больше зависит от времени компрессии и декомпрессии (например, у аппаратуры, предназначенной для поддержки видеоконференций, проведение компрессии и декомпрессии занимает порядка 220 мс), чем от коммутаторов или маршрутизаторов, сама сеть (особенно в крупных организациях) также может вносить значительные задержки. Вообще говоря, именно задержка определяет то, насколько пользователям удобно работать. Совокупная задержка при передаче видеоинформации представляет собой сумму задержек, вносимых при компрессии/декомпрессии на конечных станциях, и задержек на промежуточных устройствах в сети между абонентами. В результате, совокупная задержка может изменяться в зависимости от объема трафика в сети в определенный момент времени. Например, если говорить о передаче аудиоинформации, то проведенные исследования показали, что задержка в 50 мс практически не ощутима; если задержка находится в пределах 250-300 мс, это может вызвать некоторое раздражение абонентов, а при задержке в 600 мс и более качество воспроизведения речи становится неприемлемым.

Задержка при передаче информации по сети – а она, как мы видели, должна быть прибавлена к общей задержке – меняется в широких пределах. Для видеоконференций Н.320 по коммутируемым каналам ISDN задержка в сети составляет менее 10 мс и является постоянной величиной. В локальной сети на базе коммутаторов задержки составляют, как правило, менее 80 мс, но иногда возникают ситуации, когда они оказываются намного больше этого значения.

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