64Научно-технические разработки

предыдущая статья | оглавление | в архив | следующая статья



АТМ и IP. Перспективы сосуществования


А. Бителева Теле-Спутник - 6(92) Июнь 2003 г.


Сегодня в качестве способов транспортировки мультимедийных данных, в том числе компрессированного видео, рассматриваются две конкурирующие технологии — АТМ и IP. У каждой из них есть свои сторонники и противники. Рассмотрим особенности и перспективы этих технологий.

ATM (Asynchronous Transfer Mode), появившаяся более 10 лет назад, была задумана в качестве универсальной законченной сетевой технологии. Ее универсальность заключается в том, что она в равной степени приспособлена для передачи — голоса данных, аудио и видео, а законченность в том, что она может использоваться как в магистралях, так и в сети доступа, или локальной сети, при необходимости доходя до терминала отдельного пользователя.

В АТМ-сетях все типы трафика передаются пакетами фиксированной длины, называемыми ячейками. Длина каждой ячейки составляет 53 байта, из которых 5 занимает заголовок, а 48 — полезная информация. Такая длина была выбрана в качестве компромисса между потребностью телекоммуникационных служб в коротких ячейках и операторов компьютерных сетей в длинных.

Инкапсуляция данных в АТМ-ячейки проводится с помощью протоколов AAL (ATM Adaptation Layer). В зависимости от характера данных, для этой цели выбирается один из пяти таких протоколов. AAL решает две задачи — во-первых, распределяет данные по АТМ-ячейкам, а во-вторых обеспечивает условия передачи, требуемые для данного приложения. На этом уровне могут обеспечиваться механизмы сохранения синхронизации, устанавливаться приоритеты ячеек, формироваться режимы их выдачи в АТМ-сеть из буфера интерфейса, закладываться механизмы выявления и восстановления ошибок. Этот уровень называется уровнем конвергенции, видимо потому, что формируемая там служебная информация позволяет восстановить поток без потери качества.

Так, например, компрессированное видео очень чувствительно к задержкам и неравномерности его передачи в сети. Протоколы AAL активизируют различные механизмы компенсации этих проблем. Часть из механизмов позволяет регулировать скорость выдачи информации из буферов входных и выходных интерфейсных устройств, а другая часть — компенсировать расхождения в программных метках времени, то есть поддерживать синхронизацию приемника и передатчика потока MPEG-2. Выбор типа адаптационного протокола, а также механизмов поддержания QoS — неоднозначная задача, которую оператор сети должен решать индивидуально.

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

ATM-технология основана на установлении предварительных соединений между передающей и принимающей стороной. Но соединение это носит виртуальный характер. Путь выбирается с помощью программного анализа структуры сети и топологии передаваемых по ней потоков. Он пролегает через определенное количество промежуточных АТМ-коммутаторов, в таблицы соединений которых заносится соответствующая информация. При поступлении на порт коммутатора ячейки с данными он перенаправляет ее на другой порт, указанный в таблице. Совокупность соединений формирует виртуальный канал virtual channel (circuit) connections (VCC), переносящий данный информационный поток.

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

Передача на базе коммутации каналов обеспечивает АТМ-сетям два важных достоинства, в отличие от маршрутизируемых IP-сетей.

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

Все это обеспечивает АТМ-коммутаторам высокую пропускную способность, необходимую в магистральных линиях.

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

Универсальная система качества обслуживания QoS, разработанная для АТМ, может соответствовать требованиям к передаче информации любого типа.

В АТМ выделяются 5 категорий (классов) обслуживания, в рамках каждой из которых установлен набор нормируемых параметров качества.

1. Constant Bit Rate (CBR) — постоянная скорость передачи. Используется при обслуживании приложений, требующих постоянной полосы и чувствительных к задержкам передачи.

Этот класс обслуживания позволяет эмулировать физическое соединение. Используется при передаче телефонии, видео с постоянной скоростью и видеоконференций.

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

2. Real time Variable Bite Rate — переменная скорость передачи в реальном времени.

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

3. Non-real time Variable Bite Rate — переменная скорость передачи вне реального масштаба времени.

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

4. Available bit rate — доступная скорость передачи.

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

5. Unspecified Bit Rate — незаданная скорость передачи.

Ограничивается пиковая скорость. Категория широко используется для передачи трафика IP/TCP.

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

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

Другая причина дороговизны — небольшой по сравнению с IP-интерфейсами объем их производства.

Второй недостаток — довольно низкая эффективность использования емкости транспортных ячеек. Почти 10 процентов емкости уходит на заголовок. Еще часть поглощается информацией, вносимой протоколами AAL. А если учесть, что данные, передаваемые через АТМ, как правило, уже укомплектованы в собственные транспортные кадры, и сами АТМ-потоки передаются по телекоммуникационному кольцу SDH, то в результате получается громоздкая многоуровневая структура с большим количеством заголовков, реализующих управление на своем уровне.

Тем не менее, длительное время АТМ не имела конкурентов при строительстве транспортных сетей для передачи мультимедиа, в том числе потоков MPEG-2. Аналоговые сети (передача без использования цифровой транспортной технологии) пригодны только для небольших расстояний. Чисто телекоммуникационные технологии предназначены для передачи с постоянной скоростью, причем длина ячеек и ширина каналов оптимизированы под транспортировку мультиплексированных голосовых потоков. Они плохо пригодны для передачи потоков с переменной скоростью, а также для динамического установления и сброса соединений, часто требуемого при передаче мультимедиа и видео.

IP-сети, с маршрутизацией IP-пакетов, первоначально также не рассматривались как альтернатива АТМ. Это было обусловлено несколькими причинами.

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

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

Для передачи больших объемов IP-трафика применялись и продолжают применяться АТМ-магистрали. С учетом значительности средств, заложенных в их строительство, ожидать их скорой замены другими решениями, даже более эффективными, не приходится.

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

В телевидении IP-технология сперва стала применяться в локальных сетях, соединяющих студийные устройства, где не требуется сложное администрирование потоков.

Устойчивые позиции АТМ завоевала только как технология для построения транспортных магистралей. Однако IP-технология начала вытеснять ее и из этой области. Отчасти этому способствует появление скоростных маршрутизаторов. Сегодняшние магистральные интерфейсы Ethernet могут обслуживать потоки до 10 Гбит/с.

Одновременно разработан ряд протоколов, позволяющих решить проблему с обеспечением качества обслуживания в IP-сетях, в том числе при передаче компрессированного видео.

Один из них, Real Time Transport Protocol (RTP), предназначен для передачи данных в реальном масштабе времени. Протокол в первую очередь предназначен для применения в IP-среде, но может работать и с другими протоколами, в частности AAL5/ATM, который часто используется для передачи потоков MPEG-2 с переменной скоростью.

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

Другая функция RTP — компенсация задержек и, отчасти, неравномерности передачи пакетов (джиттер). Для этой цели в заголовок протокола вводятся метки времени, позволяющие расставить пакеты в нужном порядке в том случае, если временные уходы не компенсируются временными метками времени, введенными в кадр самого приложения. Эта функция актуальна при передаче компрессированного видео, чувствительного и к задержкам, и к джиттеру. Особенно это касается транспортных сетей, на выходе которых восстанавливается поток ASI, к качеству которого стандарт DVB предъявляет жесткие требования.

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

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

RTP поддерживает одноадресную и многоадресную передачу.

Он может работать совместно с протоколом Real Time Control Protocol (RTCP), обеспечивающим обратную связь с абонентом и некоторые функции синхронизации потоков, относящихся к одному приложению.

Использование RTP помогает решить некоторые вопросы, связанные с качеством обслуживания, но гарантированного качества обеспечить не может. Для этого еще требуется наличие необходимых сетевых ресурсов, которые будут потрачены на передачу приложения. В IP-сетях, одновременно обслуживающих множество независимых задач, такую гарантию можно дать, только заранее зарезервировав ресурсы на пути следования пакетов с данными. Эта задача решается с помощью протоколов резервирования, самый распространенный из которых — Resource reservation protocol RSVP.

При предварительном заказе услуги (например, программы платного ТВ) терминал абонента посылает запрос на резервирование канала требуемой ширины, а также приоритета обслуживания.

Этот запрос поочередно проверяется в шлюзах Интернет, встречающихся на пути к головной станции. Если в каком-то шлюзе по пути следования требуемого ресурса не оказывается, то резервирование в предыдущих шлюзах сбрасывается, и услуга не предоставляется. Состояние канала постоянно контролируется и во время передачи.

RSVP поддерживает многоадресное вещание (multicast), объединяя запросы от разных абонентов в единую многоадресную заявку.

Работа протокола RSVP в сети может управляться протоколом Common Open Policy Service (COPS), позволяющим централизованно координировать резервирование ресурсов.

Для резервирования канала и ресурсов маршрутизатора RSVP должен получить информацию о характере потребностей передаваемого приложения. Информация о требуемом уровне обслуживания формируется еще одним классом протоколов, к которому, в частности, относится Differentiated Services (DiffServ). Этот протокол добавляет в IP-пакеты информацию о наборе параметров, которым должна соответствовать их передача. Протокол DiffServ определяет 64 варианта требований к качеству обслуживания. Эти варианты в разных сочетаниях учитывают чувствительность потока к потерям, задержкам, джиттеру, возможность пиковых нагрузок и т.д.

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

Однако, так же, как и в АТМ, система получается довольно громоздкой. Кроме того, в отличие от АТМ она страдает недостаточной отработанностью и отсутствием комплексного подхода к управлению всем этим механизмом.

Эти недостатки должны быть преодолены в рамках разрабатываемой сейчас серии протоколов MPLS. MPLS — протокол скоростной маршрутизации пакетов с помощью меток по принципу, схожему с используемым в АТМ.

Область действия IP, MPLS и GMPLS

При входе в зону действия MPLS IP-пакет получает метку, которая определяет его маршрут до следующего MPLS-маршрутизатора. Метка назначается в соответствии с точкой назначения пакета, а также параметрами передачи, определяемыми требованиями QoS. Следующий MPLS-маршрутизатор присваивает пакету новую метку, которая определяется по хранящейся в нем таблице обмена и перенаправляет пакет на порт, соответствующий метке. Формирование таблиц обмена метками предполагает проведение предварительной оценки ресурсов сети и резервирования канала, соответствующего заданным параметрам обслуживания. Эта работа проводится с помощью вспомогательных протоколов, в том числе перечисленных выше. Ее результатом является формирование и периодическое обновление таблиц обмена. Степень надежности предоставления канала может колебаться от гарантированного выделения канала с дополнительным резервированием до предоставления ресурсов по принципу "лучшее из возможного".

С появлением скоростных маршрутизаторов фактор скорости перестал восприниматься как основное достоинство MPLS-технологии.

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

Принцип работы MPLS аналогичен АТМ, поэтому задача формирования данных для таблиц коммутаторов АТМ при подготовке канала сильно упрощается.

Идея интеграции уровней с помощью меток получила продолжение в разработке протокола MPlS. Он предназначен для управления маршрутизацией в иерархических транспортных сетях IP/ATM/SDH, работающих на базе оптико-волоконных сетей с волновым уплотнением спектра DWDM. Он предусматривает формирование меток, управляющих непосредственно DWDM-коммутатором, то есть на базе характеристик потока формируются метки с указанием длины волны, на которой поток должен передаваться от одного узла к другому.

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

Таким образом, встала задача вывода MPLS за рамки обслуживания IP-сетей и обучения его "языку" телекоммуникационных сетей.

Так родилась идея создания технологии Generalized Multi-Protocol Label Switching GMPLS, на базе которой в будущем предполагается строить интеллектуальные оптические сети. По замыслу разработчиков устройства, входящие в эту сеть и поддерживающие MPLS, будут автоматически анализировать состояние сети и выделять необходимые ресурсы для передачи различных служб.

Анализ состояния должен включать обнаружение наличных ресурсов сети рядом с собой, определение их статуса (типа устройства) и постоянную проверку качества соединения с ними.

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

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

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

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



 
Теле-Спутник Июнь 2003
наверх
 



Уважаемые посетители!
В связи с полной реконструкцией Архива, возможны ситуации, когда текст будет выводиться не полностью или неправильно (отсутсвие статей в некоторых номерах это не ошибка). Если заметите какие-то ошибки, то, пожалуйста, сообщите нам о них. Для связи можете воспользоваться специальной формой:

Номер журнала: *
Страница: *
Дополнительные сведения: *
Желательно четко опишите замеченную проблему - это поможет быстрее ее решить.
Мы не отвечаем на вопросы! Их следует задавать на нашем форуме!
Антиспам: * Нажмите мышкой на синий квадрат:


Поля, помеченные звездочкой (*)
обязательны для заполнения





Новый сайт