ATM получает все более широкое распространение. Предлагаемые рекомендации помогут вам перейти от frame relay к этому универсальному режиму передачи данных.
Когда первые "Форды" модели Т с двигателями в двадцать лошадиных сил появились на улицах американских городов, многим показалось, что они оказались в центре технологического водоворота. Позднее, когда "Конкорды" стали бороздить небо со скоростью 2 Маха, пал еще один барьер скорости. За свою историю сетевой мир преодолел аналогичные препятствия, но быстрота перехода от frame relay к ATM такова, что администраторы сетей не поспевают следить за происходящими изменениями.
В статье "Как выиграть гонку frame relay", в которой говорится о переходе к высокоскоростным технологиям для глобальных сетей, мы рассказываем об изменении требований к корпоративным сетям и последствиях этих изменений для архитектуры глобальных сетей. Изменения касаются не только frame relay, поскольку frame relay - всего лишь ступенька на эволюционной лестнице средств передачи данных.
Одним из важнейших элементов этой эволюции является изменение значения термина "данные". В свое время этим словом обозначалась информация, хранимая и передаваемая на бумаге, - текстовые документы, таблицы, рекламные буклеты, графика и проч. Усложнение технологии, а также повышение запросов пользователей привело к необходимости интеграции разнообразных форматов представления информации. Теперь помимо традиционных типов данных сеть должна передавать нестандартные виды информации, в том числе видео и голос.
Передача данных сегодня требует большей пропускной способности. Это требование стимулировало появление технологии следующего поколения: ATM. Однако данная технология находится на самой ранней стадии развертывания, ввиду чего полностью функциональные решения, увы, пока недоступны.
Организациям, планирующим внедрение приложений, требующих высокой пропускной способности, не обойтись без ATM. Включение ATM в планы расширения frame relay сделает миграцию к ATM в будущем беспроблемной и насколько только возможно доступной по цене. Для этого организации должны вначале твердо определиться во взаимоотношениях друг с другом на техническом уровне и уяснить для себя основные возможности перехода.
ДОРОГУ ОСИЛИТ ИДУЩИЙ
Традиционно, глобальные и локальные сети были взаимоисключающими средами в том, что касается технологий и архитектуры. Одной из направляющих сил развития таких технологий, как frame relay и ATM, является стремление к унификации этих разнородных сред с целью получения однородной системы. Сеть, использующая подобные технологии как на локальном, так и на глобальном уровне, много проще и дешевле в эксплуатации.
В результате перехода к frame relay глобальные сети приобретают архитектуру и функциональные характеристики, типичные для локальных сетей. Глобальные сети такого типа более распределенные, более гибкие и быстрые, чем традиционные глобальные сети в топологии точка-точка или multidrop. В качестве недостатка отметим, что, поскольку frame relay используется практически исключительно в глобальной части сети, эти конфигурации содержат изолированные технологии.
На следующем этапе эволюции - ATM - мы имеем технологию, благодаря которой организации могут применять один и тот же набор стандартов как к глобальной, так и локальной частям крупной сети. Другое преимущество ATM заключается в наличии путей перехода к ATM как для локальных, так и для глобальных сетей, несмотря на то, что сегодня они продолжают использовать весьма различные между собой решения. На глобальном уровне эти пути подразумевают переход от frame relay и других высокоскоростных технологий глобальных сетей, например служба многомегабитовой коммутации данных (Switched Multimegabit Data Service, SMDS).
На локальном уровне миграционный путь может включать промежуточный этап в виде высокоскоростной коммутации Ethernet или Token Ring, благодаря чему дорогостоящие, быстрые и многофункциональные решения на основе ATM могут быть реализованы только там, где они действительно необходимы. Такие промежуточные коммутационные технологии обеспечивают инфраструктуру, в которую оборудование для ATM может внедряться без проблем.
ЯБЛОКИ И АПЕЛЬСИНЫ
Несмотря на то что и frame relay, и ATM представляют собой, в первую очередь, протоколы второго уровня для высокоскоростных технологий коммутации, между ними имеются существенные различия. Эти различия касаются формата кадров, архитектуры и приложений. Frame relay использует, как следует из названия, кадры, в то время как ATM - ячейки. Основное различие между кадрами и ячейками состоит в том, что кадр имеет произвольную длину (в смысле количества содержащихся в нем бит или байт), а ячейки фиксированы по размеру. Длина кадра frame relay колеблется в пределах от 256 байт до более чем 8000 байт; длина ячейки ATM всегда равна 53 байтам.
Высокая скорость передачи данных ATM объясняется, в частности, фиксированной длиной ячейки, благодаря чему отпадает необходимость в оборудовании для проверки длины передаваемых пакетов. (Ясно, что при этом накладные расходы на обработку сокращаются.) Рис. 1 и 2 демонстрируют базовые структуры кадров и ячеек frame relay и ATM.
(1x1)
Рисунок 1.
Кадры frame relay имеют разную длину, в результате чего этот протокол
обладает меньшей пропускной способностью, чем ATM, так как оборудование
управления трафиком вынуждено отслеживать длину пакетов. Что касается адресных
и управляющих полей, кадры этого протокола обладают одинаковой структурой.
(1x1)
Рисунок 2.
Ячейка ATM имеет два возможных формата заголовка: формат сетевого интерфейса
пользователя и формат межсетевого интерфейса. Какой формат используется,
зависит от местонахождения ячейки в сети. Форматы различаются прежде всего
полем управления потоком.
Как показано на Рис. 2, помимо отличий в длине ячейки ATM имеют более одного возможного формата заголовка ячейки. У кадра frame relay всегда одна и та же структура адресных и управляющих полей, в то время как ячейка ATM может иметь заголовок одного из двух различных форматов в зависимости от местонахождения ячейки в сети. Для ячеек между сетью, или облаком, и оборудованием внутри здания используется формат заголовка сетевого интерфейса пользователя (User-to-Network Interface, UNI). Для трафика внутри облака или между сетями применяется формат заголовка межсетевого интерфейса (Network-to-Network Interface, NNI).
Заголовки UNI и NNI довольно похожи, за тем исключением, что первое поле заголовка UNI - это 4-битное поле управления потоком (GFC), а второе - это 1-байтное (8-битное) поле идентификатора виртуального пути (VPI). В заголовке NNI поле GFC отсутствует, а поле VPI имеет длину 12 бит.
Еще одно различие между ATM и frame relay состоит в определении высокоуровневого интерфейса. Стандарт frame relay слагает с себя ответственность за решение таких вопросов, как коррекция ошибок и т.п., возлагая эти функции на высокоуровневые протоколы. Такое разделение полномочий хорошо подходит для большинства сервисов frame relay, потому что данный протокол был предназначен в первую очередь для передачи собственно данных, а не таких чувствительных к задержкам и ошибкам типов данных, как голос и видео.
Протоколы типа SNA более требовательны в отношении протоколов первого и второго уровня, чем frame relay в отношении высокоуровневых протоколов. Запросы для отзыва (RFC) 1294, 1434, 1490 и 1795 были специально разработаны для описания интерфейсов между frame relay и специфическими высокоуровневыми протоколами типа SNA и IP.
Тот факт, что стандарт frame relay допускает кадры свыше 8000 байт длиной, сводит к минимуму необходимость в фрагментации высокоуровневых блоков данных. Однако большинство поставщиков предпочитают ограничивать длину кадров за счет использования схем фрагментации и инкапсуляции. Неудивительно, что фрагментация и инкапсуляция являются, по сути дела, основными вопросами в вышеупомянутых RFC.
Минималистский подход frame relay позволяет получить относительно простой стандарт, вполне оправдывающий заявления сторонников frame relay о том, что данная технология прозрачна для высокоуровневых протоколов - утверждение, правдивое ровно настолько, насколько это необходимо, чтобы навлечь на вас неприятности.
БОЛЬШИЕ НАДЕЖДЫ
Так как стандарт ATM является частью более широкой программы разработки стандартов широкополосной ISDN (BISDN), интерфейс ATM с высокоуровневыми протоколами определен более подробно, чем в случае frame relay. Это вызвано, по крайней мере отчасти, связываемыми с ATM надеждами. Frame relay создавалась, главным образом, как глобальная технология передачи только текстовых данных. Голос и видео передавать по frame relay можно, но это требует большой изобретательности (о проблемах и возможностях передачи голоса по frame relay см. врезку "Frame relay и голос"). ATM, с другой стороны, с самого начала задумывался как универсальная технология для передачи самых разных видов информации на больших скоростях с разными требованиями к качеству передачи.
Вообще-то, ATM имеет три типа сервисных интерфейсов. Эти классы интерфейса для высокоуровневых сервисов называются уровнями адаптации ATM (AAL).
В технической литературе об уровнях адаптации ATM можно найти упоминание от трех до пяти AAL. Первоначально было определено четыре уровня, после чего уровни 3 и 4 объединили. Затем появился пятый уровень. В настоящее время рассматривается предложение исключить AAL-2.
В настоящее время функциональными являются AAL-1, AAL-3/4 и AAL-5. Большинство разрабатываемых и готовых продуктов ведущих отраслевых производителей предоставляют именно эти три класса услуг.
Каждому из данных AAL соответствует своя структура подячейки в информационном поле (см. Рис. 3) в зависимости от класса услуг, за которые он отвечает. Эта подячейка AAL называется протокольным блоком данных (PDU).
(1x1)
Рисунок 3.
Каждый уровень адаптации ATM (AAL) имеет уникальную структуру подячейки.
AAL-1 обменивается сервисными блоками данных с высокоуровневыми протоколами
и приложениями. Он также передает параметры высокоуровневых сервисов для
отслеживания ошибок при передаче.
На Рис. 3 формат PDU для AAL-1 дает пример того, как AAL PDU соотносится с ячейкой ATM. Каждый AAL имеет свои заголовок и формат подячейки в зависимости от его обязанностей в отношении высокоуровневых сервисов. AAL-1 отвечает за высокоуровневые сервисы с постоянной скоростью в битах (Constant Bit Rate, CBR). Данный уровень адаптации структурирован для обмена сервисными блоками данных (Service Data Unit, SDU) с высокоуровневыми протоколами и приложениями с постоянной скоростью. Помимо информационного содержимого AAL-1 передает также специфические для высокоуровневых сервисов параметры, например неисправляемые утерянные данные или ошибки между передающим и принимающим устройствами.
Трафик AAL-1 изохронный. Это означает, что он состоит из одинаковых блоков данных с известными постоянными интервалами между ними. Такой тип трафика чувствителен к потерям и порче блоков данных, плохо поддается сжатию и приводит к ухудшению качества даже при относительно небольших изменениях в задержке на распространение. Тем не менее AAL-1 способен надежно обрабатывать голос, видео или данные.
Трафик AAL-2, который может и не войти в окончательный стандарт, также предназначен для голоса и видео. Этот уровень адаптации предусматривает преобразование трафика с постоянной скоростью в битах в надежный трафик с переменной скоростью в битах. AAL-1 структурирован прежде всего с учетом передачи видео и голоса. Передача других типов данных при этом обычно не проблематична, потому что трафик AAL-1 весьма терпим к прерываниям. Структура же AAL-2 соответствует больше природе трафика данных (пакеты, разные скорости передачи).
AAL-2 PDU требует временной отметки для каждого PDU, очень чувствителен к своевременности доставки и предусматривает значительные затраты на обработку ошибок. Данный подход имеет очевидные трудности в реализации, поэтому он до сих пор полностью не определен.
Изначально AAL-3 определялся как ориентированный на соединение, а AAL-4 не предусматривал установление соединения. Эти два уровня адаптации были объединены в AAL-3/4 без установления соединения. Сервисы, ранее отводимые AAL-3, включены в AAL-5. Модифицированный AAL-3 (3/4) предназначен для режима сообщений при передаче данных в виде кадров и для низкоскоростных данных, нечувствительных к задержкам.
AAL-5 был предложен поставщиками для решения проблемы высоких накладных расходов AAL-3 и сокращения размеров квитанции о получении пакета TCP/IP до одной ячейки вместо двух в AAL-3. Понимание AAL-5 весьма важно, так как он играет важную роль при переходе от frame relay к ATM.
AAL-5 предназначен для использования в локальных сетях. Он делает полезную нагрузку ячеек максимальной за счет сокращения информации о сборке до поля идентификатора виртуального канала (VCI) в заголовке ячейки. Данный класс услуг использует поле типа полезной нагрузки для указания типа сообщения и, используя фиксированное число элементов полей, сообщает принимающему устройству о том, что данная ячейка является началом, серединой или концом высокоуровневого блока данных. Принимающее устройство начинает выстраивать ячейки в очередь при получении кода типа полезной нагрузки начального блока данных. Когда устройство получает код типа полезной нагрузки конечного блока данных, оно собирает ячейки, осуществляет обработку ошибок и передает блок данных дальше.
ФОРМА И ФУНКЦИЯ
С архитектурной точки зрения, frame relay и ATM имеют некоторые общие элементы. Например, они оба являются высокоскоростными коммутационными технологиями и, с концептуальной точки зрения, ведут себя как облако. Это означает, что узел конечного пользователя имеет одно соединение с узлом и одно соединение с облаком; он может сообщаться с любым другим узлом, подсоединенным к облаку, при условии правильности конфигурации и адресации. Кроме того, и frame relay, и ATM прежде всего протоколы второго уровня, они существенно опираются на возможности высокоуровневых протоколов при осуществлении таких функций, как коррекция ошибок (помимо заголовка).
В то же время эти два подхода имеют множество архитектурных различий. ATM характеризуется гораздо более высокими темпами передачи данных и может работать с разнообразными видами данных. Если область применимости frame relay ограничена в основном глобальными сетями, то ATM способен передавать ячейку от конечной станции пользователя по глобальной и локальной части корпоративной сети к рабочей станции или хосту на другом конце. Ограничение применимости frame relay глобальными сетями требует установки в узле конечного пользователя оборудования для преобразования данных в соответствии с локальным транспортным протоколом. Наличие точки преобразования приводит к задержкам и, потенциально, к перегрузкам. До начала внедрения ATM данный фактор не принимался в расчет при проектировании в сети, потому что практически все технологии передачи данных по глобальным сетям имели то же ограничение.
Другое архитектурное различие между frame relay и ATM касается управления потоком. Frame relay использует поля явного уведомления о перегрузке вперед и назад (FECN и BECN), состоящие из заголовка кадра и бита разрешения на отбраковку (Discard Eligible, DE).
Подходы FECN и BECN являются обычно взаимоисключающими в том смысле, что поставщики применяют только один из них. ATM использует комбинацию поля GFC и бита приоритета потери ячейки (CLP). Адресные компоненты - DLCI для frame relay и VPI и VCI для ATM - сходны в том, что они, в отличие от IP-адресов, имеющих глобальное значение, имеют только локальное значение.
Создание ATM преследовало амбициозные цели: разработка сверхвысокоскоростной технологии для обработки информации практически в любой электронной форме - от данных до голоса и видео - без снижения эффективности от одного конечного пользователя до другого. Сложность и расширенные возможности ATM, по сравнению с frame relay, отражают эти цели.
ДОРОГИ К ATM
Что касается путей перехода от frame relay к ATM, то Frame Relay Forum опубликовал два метода перехода: frame relay/ATM PVC Network Interworking (FRF.5) и frame relay/ATM PVC Service Interworking (FRF.8).
Рекомендации FRF.5 касаются организации межсетевого взаимодействия между постоянным виртуальным каналом в сети frame relay и соединением виртуальных каналов (VCC или комбинация полей VCI и VPI) сети ATM. Предлагаемые рекомендациями методы организации межсетевого взаимодействия описываются двумя терминами: инкапсуляция протоколов и отображение протоколов. Инкапсуляция протоколов имеет место, когда сеть или оборудование в помещении заказчика (CPE) используют сервисы одного протокола для вставки протокольной информации другого протокола без изменения. Отображение протоколов имеет место, когда сеть или оборудование в помещении заказчика преобразует протокольную информацию одного протокола в протокольную информацию другого.
В рамках этого рабочего соглашения инкапсуляция или отображение осуществляется за счет использования функции взаимодействия frame relay/ATM (Interworking Function, IWF). IWF необходима для поддержки передачи сервисов PVC frame relay по сети ATM. IWF обеспечивает все функции инкапсуляции и отображения, необходимые для того, чтобы предоставляемая протоколом frame relay услуга оставалась неизменной при наличии транспортной сети ATM. IWF поддерживает следующие возможности протокола frame relay:
· формат PDU переменной длины;
· обнаружение ошибок;
· мультиплексирование соединений;
· индикация приоритета потерь;
· индикация перегрузок;
· управление статусом PVC.
Формат PDU переменной длины и управление статусом PVC определены в первых рабочих соглашениях Frame Relay Forum и поддерживаются прозрачно в транспортной сети ATM. Обнаружение ошибок для PDU frame relay осуществляется в AAL-5 PDU при помощи 32-разрядного механизма контроля с использованием циклического избыточного кода.
Мультиплексирование соединений может осуществляться как "один к одному" (в этом случае каждый PVC отображается на один ATM VCC), так и как "многие к одному" (в этом случае несколько PVC отображаются на один ATM VCC). Мультиплексирование соединений многие к одному поддерживается только тогда, когда несколько PVC frame relay оканчиваются в одной конечной системе на базе ATM. Индикация приоритета потерь обеспечивается посредством отображения поля DE протокола frame relay на поле CLP протокола ATM.
Индикация перегрузок часто оказывается сложным процессом с двумя возможными сценариями: трафик frame relay в сеть ATM и трафик ATM в сеть frame relay. Если FECN необходим при передаче трафика frame relay в сеть ATM, то FECN на уровне кадра копируется без изменений в AAL-5 PDU. Однако FECN не отображается на поле явной индикации перегрузки впереди на уровне ячейки (EFCI) в заголовке AAL-5 PDU, так как он всегда установлен в положение отсутствия перегрузки впереди. Если BECN необходим при направлении передачи от frame relay к ATM, то поле BECN в AAL 5 PDU задается, либо когда задано поле BECN протокола frame relay, либо когда задано поле EFCI последней ячейки ATM. Если трафик ATM направляется в сеть frame relay, поле EFCI на уровне ячейки определяет задание поля FECN или BECN.
Рис. 4 демонстрирует поддерживаемые IWF сценарии взаимодействия. Когда сеть frame relay или CPE общается с другой сетью frame relay или CPE, транспортная сеть ATM не видна каждой из них. Комплекты протоколов конечного пользователя не подвергаются никаким изменениям, потому что IWF предоставляет все необходимые функции для обеспечения прозрачной передачи. Такой сценарий называется передачей frame relay поверх ATM.
(1x1)
Рисунок 4.
Функция взаимодействия осуществляет как поддержку frame relay поверх
ATM, так и коммуникации, при которых транспортная сеть ATM прозрачна для
сети frame relay или оборудования в помещении заказчика (CPE).
При другом сценарии сеть frame relay или CPE может взаимодействовать с ATM CPE, при этом транспортная сеть ATM невидима для сети frame relay или CPE. Однако транспортная сеть ATM видима для ATM CPE, поскольку оборудование должно поддерживать специфический подуровень услуг Frame Relay Service Specific Convergence Sublayer (FR-SSCS) в своем стеке протоколов. Данный подуровень идентифицирует различные характеристики протокола frame relay и помещает эту информацию в общую часть AAL 5 PDU. IWF обеспечивает все необходимые функции для того, чтобы сервис, предоставляемый сети frame relay или CPE, был прозрачен при наличии транспортной сети ATM.
АЛЬТЕРНАТИВНЫЕ ПУТИ
FRF.8 так же, как и FRF.5, применяется при взаимодействии пользователя сервисов frame relay с пользователем сервисов ATM. Правда, в этом случае ни пользователю сервисов frame relay, ни пользователю сервисов ATM не требуется выполнять каких-либо непривычных, специфических для сервиса функций. Напомним, что в предыдущем сценарии поддержка FR-SSCS в своем стеке протоколов осуществлялась оборудованием ATM в помещении заказчика. Это означает, что ATM CPE должно быть сконфигурировано с учетом взаимодействия с любой удаленной сетью frame relay или CPE. С FRF.8 таких проблем нет: все функции взаимодействия осуществляются IWF, а ATM CPE даже не знает, что какие-то удаленные устройства подсоединены к другой службе.
При поступлении кадра frame relay в транспортную сеть ATM, система отображает его на AAL-5 PDU посредством отделения флагов кадра frame relay, нулевых битов и 16-разрядного кода CRC. AAL-5 PDU обеспечивает описание кадра и контроль ошибок CRC-32.
При поступлении ячейки ATM в транспортную сеть frame relay идентифицируются границы кадра при помощи полей описания сообщения AAL-5 PDU, вставляются нулевые биты и определяется 16-разрядный код CRC. Протокольные поля и функции AAL-5 PDU, полученного от пользователя сервисов ATM, преобразуются в соответствующие им в frame relay.
При поступлении кадра frame relay в транспортную сеть ATM разрешение на отбраковку может преобразовываться двумя способами. Функция IWF должна поддерживать тот способ, которым поле DE кадра frame relay отображается на поле ATM CLP. IWF должна также утвердить каждую ячейку, полученную в результате сегментации AAL-5 PDU и содержащую информацию о данном кадре. При желании во время подписки на предоставление услуг IWF может поддерживать задание постоянного значения ATM CLP для каждой полученной в результате сегментации ячейки.
При поступлении ячейки ATM в транспортную сеть frame relay функция IWF задаст поле DE кадра frame relay, если поле CLP задано в одной или нескольких ячейках ATM. Другой возможностью является задание поля DE равным постоянному значению во время подписки на предоставление услуг. Если говорить проще, гибкость определяется уровнем загрузки сети, в зависимости от которой отбраковка блоков данных может быть или динамической (задается отдельно для каждого кадра или ячейки), или статистической (задается постоянное значение).
При перегрузке в обоих направлениях передачи IWF динамически задает поля FECN или EFCI. Протокол ATM поддерживает только оповещение о перегрузке вперед по направлению передачи, поэтому у поля BECN нет эквивалента в протоколе ATM. IWF игнорирует поле BECN, когда кадры frame relay поступают в транспортную сеть ATM, и задает это поле равным нулю, когда ячейки ATM поступают в транспортную сеть frame relay.
Соответствие между DLCI и VCC при преобразовании адресных полей взаимооднозначно. Такая ситуация имеет место в случае PVC.
Кроме того, FRF.8 подробно описывает управление PVC в frame relay, управление VCC в ATM, инкапсуляцию высокоуровневых протоколов, мостовые и маршрутные PDU, определение адресов и ориентированные на соединение протоколы. Доступ к этому и другим рабочим соглашениям Frame Relay Forum можно получить, обратившись к узлу Web данной организации http://frame-relay.indiana.edu.
ДОРОЖНЫЕ РАСХОДЫ
Давайте посмотрим на значение этих довольно сложных рабочих соглашений для практики. Как FRF.5, так и FRF.8, во-первых, защищают сделанные инвестиции в сетевое оборудование и CPE для frame relay, а во-вторых, могут быть использованы для реализации сетей frame relay. Таким образом, они поддерживают существующие приложения. Если новым приложениям потребуются высокоскоростные средства передачи, то они могут воспользоваться транспортной сетью ATM. Части этих приложений, например приложениям для поиска в базе данных, может потребоваться доступ к унаследованным приложениям, при этом увеличения скорости не потребуется. Данные рабочие соглашения дают гарантию сохранения сетей frame relay для поддержки таких унаследованных приложений на базе транспортной сети ATM.
Все это хорошо. Плохо же то, что FRF.5 возлагает сложную задачу по организации взаимодействия со службой frame relay на ATM CPE. Естественно, что чем сложнее оборудование, тем оно дороже. В случае FRF.8 данная задача решается внутри сети ATM на границе между транспортной сетью frame relay и транспортной сетью ATM или функцией взаимодействия, что, в свою очередь, ведет к повышению платы за услуги. Таким образом, какой бы сценарий вы не выбрали для организации взаимодействия сетей frame relay и ATM, платить за это все равно придется.
Первые практические реализации взаимодействия между frame relay и ATM были осуществлены поставщиками CPE. В ближайшем будущем многие конечные пользователи станут использовать frame relay как службу доступа в противовес ее теперешнему использованию в качестве транспортной службы. Магистральные каналы frame relay будут заменены на каналы ATM. Это означает, что конечным пользователям придется оснастить каждый центральный участок сети frame relay, платами и каналами ATM. Оборудование CPE конечного пользователя будет осуществлять преобразование кадров frame relay в ячейки ATM. Конечные пользователи, поставщики которых не выпустят плат ATM, столкнутся с необходимостью замены оборудования в этих узлах - еще одна статья расходов.
Ознакомившись с предлагаемой нами информацией, вы, скорее всего, решите, что переход повлечет за собой лишь ненужные расходы. Однако техническую революцию не остановить. Настанет такой момент, когда пользователи потребуют доступ к приложениям, для которых транспортные средства ATM просто необходимы. Выбор поставщика, располагающего стратегией перехода, при которой нет нужды в полной замене CPE, позволит заметно сэкономить на и без того дорогостоящей модернизации сети.
Если вы располагаете сетью frame relay, то обратитесь к вашим поставщикам с просьбой о предоставлении плана организации взаимодействия и перехода к ATM. Важно начать планирование изменения сети сегодня.
Технический прогресс и конкуренция ведут к появлению надежных, многофункциональных, высокоскоростных приложений, к тому же потребность организации взаимодействия каждого с каждым становится все более неотложной, а стало быть развертывание технологий с возможностями ATM становится вопросом ближайшего будущего. Так что изречение "от прогресса никуда не деться" еще раз подтверждает свою истинность. Те, кто первыми откликнутся на веяния времени, получат наибольшие дивиденды.
Терри Парсонс работает в сетевой компании Virtual Resources. С ним можно связаться через Internet по адресу: tparsons@ix.netcom.com. Тим Бич - корпоративный менеджер офиса Bay Networks в Атланте. С ним можно связаться через Internet по адресу: tbeach@baynetworks.com.
ПРОИЗВОДИТЕЛИ РАБОТАЮТ НАД ПЕРЕДАЧЕЙ ГОЛОСА ПО FRAME RELAY
Frame relay и голос
Frame relay не собирается сдавать свои позиции ATM без боя и борется со своими недостатками, в частности с плохой приспособленностью для передачи голосовых данных. Эффективной передаче голоса препятствуют прежде всего большие задержки при передаче кадров. Пропускная способность в сетях frame relay поддерживается на задаваемом уровне производительности (CIR), и информационные пакеты со скоростью, превышающей CIR, задерживаются и/или отбраковываются; прежде всего это относится к голосовым данным.
В настоящее время Frame Relay Forum вырабатывает единый стандарт передачи голосовых данных и в первую очередь стандарт сжатия. Все больше и больше участников Форума склоняются к стандарту MPMLQ (G.723.1, 6.4 Кбит/с), так как он позволяет наиболее эффективно мультиплексировать голосовые каналы.
Борьба с задержкой голосовых пакетов ведется по двум направлениям. Во-первых, на аппаратном уровне - фиксированная задержка из конца в конец, определяемая удалением, компенсируется за счет эхопоглотителей, а с дифференциальной задержкой, обусловленной тем, что скорость прохождения пакетов не является постоянной величиной, борются при помощи буферизации. Во-вторых, за счет установления приоритетов. Самое простое решение - выделить под голосовой канал отдельный порт и задать ему достаточно высокий приоритет, но такое решение будет довольно дорогостоящим и не позволит объединить каналы данных и голоса. Более эффективна техника субадресации, основанная на двойном инкапсулировании пакетов frame relay. Голосовой канал или канал данных получает свой DLCI, но остается невидимым для сети frame relay (что очень напоминает ATM). Правда, здесь есть одно "но" - это интересы провайдеров услуг frame relay, чьи доходы зависят от числа используемых клиентом PVC (DLCI).
Предстоит также выработать еще несколько стандартов:
· единый формат голосовых сигналов должен предотвратить проблемы при интерпретации сигнальных битов (on-hook, off-hook, data-pulse) оборудованием от разных производителей;
· формат фрагментации кадров помогает в установлении приоритетов за счет фрагментирования больших кадров на сегменты. Во время передачи голосовых кадров, передача фрагментированных кадров приостанавливается, тем самым гарантируется приоритет первых.
· стандарт маршрутизации голосовых сообщений - мультиплексоры frame relay - могут быть сконструированы таким образом, чтобы позволить построение информационных и голосовых (телефонных, по сути дела) сетей без применения АТС (требуется стандартизировать режим эмуляции АТС).
Передача голоса по frame relay, конечно, не бросит вызова конкурирующим технологиям, но несомненно укрепит ее позиции, к тому же разрабатываемая для frame relay технология передачи голосовых данных уже воплощается в жизнь - в сентябре активный участник подгруппы голосовых технологий Frame Relay Forum компания RAD Data Communications собирается представить новое устройство модульного интегрального мультиплексора с пакетной коммутацией frame relay - Maxcess-3000. Если компании действительно удалось реализовать желаемое, то оппоненты frame relay лишились одного из своих козырей.