Использование АТМ в сетях на уровне предприятия ставит перед сетевыми администраторами специфические проблемы. Во-первых, они должны обеспечить единое управление потоками самой разнообразной информации - голосовой, видео, данных. А ведь каждому из них присущи свои особые характеристики передачи.
Во-вторых, все эти виды информации предъявляют собственные требования к пропускной способности, что заставляет особенно тщательно подходить к распределению и регулированию доступной полосы пропускания АТМ-канала.
В-третьих, сети АТМ нужно рассматривать на логическом уровне, опираясь на виртуальные соединения, тогда как большинство администраторов привыкло к уровню физическому, в основе которого лежит разделение ЛВС на кластеры.
Данный технический обзор посвящен различным типам трафика в АТМ-сети и способам эффективного управления ими на уровне предприятия. Кроме того, рассмотрены некоторые программные продукты, помогающие администраторам объединить управление АТМ-сетью с общей системой сетевого управления в масштабе предприятия.
Технология АТМ предусматривает несколько категорий обслуживания информационных передач, определяющих приоритетность распределения пропускной способности и присваиваемых отдельно в каждом конкретном случае. В процессе управления трафиком в первую очередь необходимо определить, какую долю общей пропускной способности сети следует выделить приложениям той или иной категории, чтобы обеспечить требуемое качество их работы.
Всего существует четыре категории обслуживания: CBR (Constant Bit Rate - фиксированная скорость передачи), VBR (Variable Bit Rate - переменная скорость передачи), ABR (Available Bit Rate - доступная скорость передачи) и UBR (Unspecified Bit Rate - неопределенная скорость передачи). Категорию VBR, в свою очередь, можно разделить на две подкатегории: VBR реального масштаба времени и VBR с задержкой.
Наивысшим приоритетом обладает категория CBR. Она присваивается той части трафика, которая предъявляет жесткие требования ко времени запаздывания сигнала. Сюда относятся передача голосовых сообщений, интерактивное видео и эмуляция цифровых каналов Т-1, DS-3 и им подобных. Для CBR-трафика выделяется фиксированная часть пропускной способности системы, а остаток распределяется между другими категориями обслуживания.
Уровень VBR предназначен для приложений, пересылка информации в которых носит “взрывной” характер. В них трафик значительно меняется во времени, поэтому для определения требуемой пропускной способности используются две характеристики: гарантированная скорость передачи ячеек и максимальный размер посылки. Первая представляет собой среднюю скорость передачи ячеек при оптимальных условиях работы канала, а вторая - наибольшее количество ячеек, которое можно переслать с максимально допустимой скоростью за время посылки.
Подкатегория VBR реального масштаба времени присваивается сеансам передачи голоса, использующим сжатие и подавление пауз, а VBR с задержкой - таким операциям, как заказ авиабилетов, проведение банковских транзакций и контроль за производственными процессами.
Если же передаваемая информация не требует гарантированной пропускной способности, то чаще всего она получает категорию UBR и использует “фоновую” полосу пропускания, т. е. не задействованную для передач уровней CBR и VBR.
Категория ABR применима к тем данным, для пересылки которых, как правило, достаточно небольшой пропускной способности, однако иногда требуется кратковременное ее повышение. В этом случае гарантируется выполнение минимальных требований приложения.
В категории ABR, в отличие от UBR, производится постоянный контроль за состоянием сетевого трафика. Это позволяет при возможности выделять пользователям дополнительную полосу пропускания. Таким образом достигается хорошее качество передачи “взрывного” трафика, характерного для ЛВС, по загруженным АТМ-сетям.
Весь ATM-трафик делится на категории обслуживания CBR, VBR и ABR или UBR.
Прохождение трафика ABR и UBR не гарантированно;
ограниченная пропускная способность сети может привести к утрате некоторых ячеек
Применение в ABR методов борьбы с перегрузкой позволяет оптимизировать использование пропускной способности сети, что делает эту категорию более предпочтительной по сравнению с UBR. Однако сетевые менеджеры должны иметь в виду: ни ABR, ни UBR не гарантирует доставку адресату всех АТМ-ячеек, часть их может быть потеряна при пересылке из-за ограниченной пропускной способности канала.
Обе эти категории хорошо подходят для приложений, использующих протоколы TCP/IP и им подобные, где предусмотрены способы восстановления утраченных данных.
Выбирая АТМ-коммутатор для своей сети, администратор не может не поинтересоваться, какие методы обработки ABR-потоков предлагает та или иная модель.
Особенно эффективно выделение гарантированной полосы пропускания на всем маршруте передачи. Как ожидается, в ближайшее время оно найдет применение во многих новых АТМ-продуктах.
Еще один эффективный способ обработки ABR-потоков состоит в разделении потока управления на два или больше сегментов. Этот метод получил название “управление виртуальным источником и виртуальным получателем” (virtual source/virtual destination control) или “поэтапное управление” (link-by-link control). При его использовании в сеть вводятся промежуточные контрольные точки (так называемые виртуальные источники и получатели), позволяющие осуществлять управление всем сетевым трафиком более точно.
При выборе коммутатора нужно обращать внимание и на то, как в нем осуществляется буферизация пакетов и назначение приоритета обслуживания различным типам трафика. Размер буферов АТМ-коммутатора оказывает очень большое влияние на производительность всей системы. Чем больший объем данных устройство способно хранить в памяти, тем менее вероятна утрата ячеек и вызванная ею необходимость их повторной передачи. При этом к структуре буферизации предъявляются особые требования: она должна обеспечивать свободное прохождение приоритетных сообщений и не наносить ущерба другим категориям обслуживания, менее требовательным ко времени запаздывания.
Для оптимального использования UBR- и ABR-трафиком пропускной способности сети очень важен алгоритм определения очередности. Дисциплина обслуживания очереди FIFO (First-In-First-Out - “первым пришел - первым обслужен”) зачастую приводит к неважным результатам. Гораздо лучший эффект дают алгоритмы, принимающие во внимание поддержку виртуальных каналов.
АТМ и SNMP
Стандарт удаленного управления сетью RMON первоначально был разработан для физических сетевых сегментов, а не логических, которые свойственны АТМ. Пока отсутствуют какие-либо соглашения о базах управляющей информации RMON для АТМ, однако фирма Cisco Systems уже выступила с инициативой разработки подобной спецификации. Такая база должна дать администраторам возможность накапливать статистические данные по количеству переданных, полученных, принятых с искажениями и утраченных из-за перегрузки сети ячеек АТМ.
Одна из проблем, возникающих при управлении сетью посредством RMON и базы управляющей информации АТМ, состоит в передаче собранной информации на административную консоль. В
SNMP Version 1 возможность пересылки больших объемов данных не предусмотрена, что делает этот протокол малоэффективным для связи устройств удаленного мониторинга с консолью сетевого управления. Снять остроту этой проблемы призвана команда “Get Bulk”, включенная в SNMP Version 2. Последняя, однако, в реальных устройствах воплощается очень медленно.
Но какую бы версию SNMP администратор ни применял для сбора и передачи управляющей информации, перед ним неизбежно возникает и еще одна проблема - отсутствие административной структуры, обеспечивающей получение и анализ сетевых статистических данных.
Продукты сетевого управления, предлагаемые некоторыми разработчиками (например, система ForeView фирмы Fore Systems), используют SNMP и осуществляют связь с такими консолями управления, как OpenView компании Hewlett-Packard. Однако подобные административные консоли создавались без учета специфических особенностей АТМ. Они не только не предоставляют администратору возможности управления подключениями, но даже не позволяют ему производить распределение работ в сети между пользователями и планировать ресурсы, что крайне необходимо для рентабельного и эффективного управления АТМ-сетью.
Внутреннее управление сетью
АТМ-Форум, главный орган в области стандартизации асинхронного режима передачи данных, разрабатывает другую систему администрирования АТМ-сетей. В ее основу положено внутреннее управление сетью с использованием так называемых ячеек ФАС (Функционирование, Администрирование, Сопровождение), или OAM (Operations, Administration, Maintanance).
Спецификация этих служебных элементов связана с моделью сетевого управления, предложенной АТМ-Форумом. Рабочая группа, ответственная за разработку данной структуры, все еще занимается функциями аварийного управления. Уже определена структура ячеек подачи сигнала тревоги, сообщений об отказах в работе, проверки целостности сети. Кроме того, описаны специальные ячейки обратной связи для проверки связности сети и решения диагностических задач.
На следующем этапе рабочая группа займется ячейками управления производительностью, которые позволят АТМ-сети контролировать собственную пропускную способность.
В дальнейшем ячейки ФАС должны обеспечить выполнение таких функций, как автоматическое реконфигурирование системы при перегрузке ее отдельных коммутаторов и согласованное повторное конфигурирование оконечных станций и других устройств. Тем самым будет обеспечено распределение функций интеллектуального управления, включая мониторинг и конфигурирование, по всей сети.
Понятно, что для окончательной разработки всех ФАС-элементов внутреннего управления потребуется некоторое время, однако работа над созданием программных средств управления, совместимых с имеющимися предложениями и спецификациями АТМ-Форума, уже начата. Выбирая коммутатор и приложения для управления сетью, обязательно обращайте внимание на то, как производитель поддерживает или собирается поддерживать использование ячеек ФАС.
Сегодня уже существуют разнообразные способы назначения уровня приоритета различным видам трафика АТМ-сетей, необходимого для эффективного использования доступной пропускной способности. И все же мониторинг трафика на всем пути прохождения по АТМ-сети по-прежнему представляет собой сложную задачу, для решения которой сетевым менеджерам приходится иметь дело со множеством инструментальных средств. Определенную помощь им способны оказать SNMP Version 2 совместно с RMON и RMON2, хотя полностью решить проблему не позволяют и эти средства. Пакетам сетевого управления, которые бы сочетали мониторинг и управление трафиком во всей сети с распределением работ и планированием ресурсов, еще только предстоит появиться. Возможно, пройдет несколько лет, прежде чем мы сможем воспользоваться ими в своей АТМ-сети.
Дейв Козюр
Данные АТМ-коммутаторов приведены в таблице “Руководство покупателя”
