(Продолжение. Начало см. PC Week/RE, №10/96, с.35)
И "кампусные", и АТМК (ATM-коммутаторы) для рабочих групп должны быть совместимы с различными оконечными системами АТМ, подключаемыми при помощи интерфейсов UNI различного типа. Раз это так, поддержка UNI чрезвычайно важна наряду с ранее стандартизованными механизмами, в частности ILMI (Interim Management Interface). Хотя сейчас многие современные АТМК не поддерживают указанные стандартные механизмы, это станет в будущем абсолютно недопустимым, поскольку появится целый ряд оконечных устройств, разрабатываемых различными компаниями. Таким образом, полное соответствие спецификации сигнального протокола UNI 3.0 будет обязательным. Существует, однако, неоднозначная ситуация со стандартом UNI 3.1, поэтому необходимо сделать ряд замечаний по этому поводу.
Сигнальный протокол UNI и протокол ILMI
Спецификации UNI 3.0, одобренные ATM Forum, в числе первых реализованы в устройствах многих фирм. Однако затем эти спецификации пересмотрели и переиздали как спецификации UNI 3.1, главным образом для большего соответствия работам комитета ITU-T - официальной организации по стандартизации АТМ. Эти изменения не добавили каких-либо новых функциональных возможностей, но сделали редакцию 3.1 несовместимой с 3.0. Это скорее теоретическая проблема, поскольку большинство компаний - разработчиков изделий для АТМ достаточно быстро реализовали UNI 3.0 и мало кто (если такие вообще существуют) - UNI 3.1. Таким образом, UNI 3.0 является стандартом де-факто наряду с официально принятой спецификацией UNI 3.1. Поддержка только стандарта UNI 3.1, следовательно, чревата потерей совместимости с изделиями всех фирм, за исключением немногочисленных новых компаний, недавно вступивших на рынок АТМ, в связи с чем ими была сделана ставка на UNI 3.1.
АТМ Forum поддерживает оба стандарта - UNI 3.0 и 3.1 - для АТМК и оконечного оборудования, и обе возможности, по-видимому, должны стать стандартными для устройств следующего поколения. Однако поддержка стандарта UNI 3.0 является более предпочтительной по сравнению с UNI 3.1. Коммутаторы следующего поколения должны быть модифицированы для поддержки спецификации UNI 4.0, создание ее должно быть закончено к середине 1996 года. Однако поддержка этой спецификации не является обязательной в ближайшее время, поскольку механизм UNI 4.0 еще не будет учтен в первых вариантах спецификаций на механизм маршрутизации, разработка которых будет завершена в ближайшее время. Поэтому спецификация UNI 4.0, вероятно, не получит широкого распространения в течение определенного времени. Реализация UNI 3.1 может рассматриваться как база для подготовки к стандарту UNI 4.0.
Определение того, какой из двух стеков протоколов должен быть использован, является одной из важных обязанностей протокола ILMI (протокола и конфигурации управления уровнем звена данных), который, в свою очередь, предназначен для работы поверх UNI. ILMI играет жизненно важную роль в автоконфигурации множества параметров, включая, в частности, адрес АТМ. Механизм регистрации адреса при помощи ILMI позволяет АТМК размещать префиксы для оконечных устройств АТМ, благодаря чему оконечные устройства могут передавать АТМК только свой уникальный MAC-адрес. Это исключает необходимость явного конфигурирования адреса АТМ в оконечном устройстве, что весьма существенно, поскольку адрес АТМ является громоздким и неудобным набором из двадцати 16-разрядных чисел. Не менее важно и то, что этот протокол позволяет управлять распределением адресов, а следовательно, обеспечивает описание сетевой иерархии и минимизирует вероятность ошибок конфигурирования.
Протокол ILMI используется и для других задач конфигурации, например для определения адресов серверов начальных конфигураций для различных сетевых протоколов. Поддержка сигнального протокола UNI и других подобных механизмов выдвигает еще одно, на первый взгляд не очевидное, требование к ресурсам процессора АТМК следующего поколения.
Протоколы маршрутизации АТМ
Как уже отмечалось ранее, протоколы маршрутизации АТМ необходимы для маршрутизации по сети из АТМ сигнального запроса и далее - для установления SVC.
Комбинация маршрутизации АТМ и межкоммутаторных сигнальных протоколов определяет совместимость АТМК, поскольку простая передача ячеек или совместимость физических интерфейсов - тривиальные задачи. Этого явно недостаточно для практического построения сетей из оборудования различных компаний. В настоящее время единственным стандартным механизмом для маршрутизации и сигнальных запросов является IISP (Interim Inter-Switch Signaling Protocol). IISP использует комбинацию конфигурируемой вручную статической маршрутизации и межкоммутаторной сигнализации UNI. Это простейшая форма маршрутизации была определена только как промежуточный шаг до появления первого настоящего метода маршрутизации АТМ - протокола P-NNI (Private NNI), фаза 1.
Протокол P-NNI, находящийся в настоящее время в стадии завершения ATM Forum, определяет полный набор сигнальных механизмов и протоколов маршрутизации АТМ. Наличие протокола IISP и появление P-NNI не оставляют оснований для дальнейшего применения нестандартных фирменных протоколов маршрутизации, которые получили распространение в текущем поколении АТМК. Это, в частности, определяется тем, что протокол P-NNI, несмотря на то что он разработан на основе существующих протоколов маршрутизации, включает в себя поддержку значительно более широких возможностей, чем у существующих протоколов маршрутизации, в частности поддержку маршрутизации QoS и масштабируемость.
Что касается уровня качества обслуживания QoS, можно сказать, что протокол P-NNI разработан для поддержки установления соединения с гарантированным качеством сервиса (или QoS), причем, естественно, любые характеристики трафика, начиная с полосы пропускания и способности переносить пиковые нагрузки и кончая задержками и фазовыми искажениями, могут быть заданы при установлении соединения и выборе соответствующего маршрута. В частности, протокол маршрутизации P-NNI позволяет АТМК обмениваться не только информацией о достижимости (в результате все коммутаторы имеют информацию о том, какие адреса АТМ достижимы через другие АТМК), но также и сообщать метрики QoS (например, какая ширина полосы пропускания, или гарантированные задержки при передаче ячеек, или фазовые искажения потенциально могут быть обеспечены при новых соединениях АТМ.
Используя информацию о достижимости, протокол P-NNI позволяет определить маршрут (с трассировкой промежуточных адресов через сеть АТМ) с высокой вероятностью того, что это соединение сможет поддерживать передачу трафика и отвечать заданному QoS. После того как маршрут с промежуточными адресами вычислен, АТМК - инициатор соединения - помещает его описание в сигнальный запрос, полученный при помощи UNI, и направляет его через сеть к оконечному АТМК. На практике существуют значительные проблемы на отдельных этапах этой процедуры. Например, существует тесное взаимодействие между протоколом маршрутизации P-NNI и механизмами управления и мониторинга в АТМ-коммутаторах. Кроме того, поскольку ни один протокол маршрутизации не может предоставить абсолютно корректную информацию о состоянии всех коммутаторов сети, должен быть задействован дополнительный механизм "проб и ошибок", необходимый для коррекции и модификации вычисленного маршрута.
Один из главных источников такого рода неточностей заключается в поддержке высокого уровня масштабируемости. Протокол P-NNI спроектирован с учетом масштабирования до практически любых размеров АТМ-сетей: от небольших университетских до, возможно, сети Internet с потенциальным числом коммутаторов в несколько миллионов. Такой уровень масштабируемости не имеет аналогий ни в одном из современных протоколов маршрутизации и делает протокол P-NNI весьма сложным; в частности, требуется поддержка многоуровневой иерархии, базирующейся на префиксах 20-байтового адреса АТМ. Нижний уровень иерархии маршрутизации в P-NNI представляет собой единственную группу, внутри которой все АТМК обмениваются всеми метриками достижимости и QoS, что можно рассматривать как аналогию одной области в протоколе OSPF.
Такие многочисленные группы коммутаторов-соседей одного уровня иерархии объединяются в группы более высокого уровня, а внутри каждой группы назначается выделенный АТМК или "лидер группы", и так далее на каждом уровне. Каждый уровень иерархии определяется префиксом в адресном пространстве АТМ. Применяя этот метод, теоретически можно получить более 100 уровней иерархии маршрутизации. Однако количество уровней должно быть адекватно размерам и особенностям конкретной сети. Цена, которую необходимо платить за поддержку масштабируемости, включает стоимость поддержки многочисленных уровней иерархии и выделения лидера группы внутри каждой группы на каждом уровне иерархии.
Однако существуют и более глубокие аспекты, касающиеся многочисленных уровней иерархии. Иерархия дает возможность решить проблемы масштабируемости. Она позволяет и одновременно требует агрегирования информации о доступности адресов, так что вся сеть в целом не имеет дело с неструктурированной адресацией. Это соответствует тем принципам, которые действуют, например, в сети Internet. Однако в отличие от протоколов маршрутизации Internet в случае АТМ требуется также поддержка QoS. Следует признать, что масштабирование означает необходимость как в агрегировании адресов, так и в агрегировании метрик QoS: ни одна сеть не сможет быть масштабируемой, если все коммутаторы сети должны передавать друг другу информацию о своих метриках QoS. Соответственно лидер группы коммутаторов предоставляет информацию о метриках QoS всей группе при помощи единого набора метрик, поэтому вся группа коммутаторов моделируется как единая группа, логический групповой узел или коммутатор (Logical Group Number), повторяя во многом путь суммирования данных о достижимости адресов для группы узлов.
Агрегирование QoS, однако, происходит с потерей точности. Таким образом, поддержка маршрутизации с QoS в сетях с развитой иерархией будет обязательно ограничена и потребует итераций, что вызовет увеличение задержек при установлении соединения. Понимание этого факта возникло достаточно давно в кругах специалистов АТМ. Возможно, что по этой причине, а также и ряду других (среди которых проблема надежности поддержки иерархии P-NNI) иерархический механизм P-NNI может быть пересмотрен после завершения разработки первой фазы протокола P-NNI.
В результате разработчикам, вероятно, придется применить поэтапный механизм при реализации P-NNI. Этот механизм должен помочь как в ускорении реализации протокола, так и в обеспечении тестирования совместимости P-NNI, который, вне сомнения, является наиболее сложным из разработанных когда-либо протоколов. K счастью, структурированная схема P-NNI облегчает такой поэтапный подход. В частности, первая фаза протокола, скорее всего, будет поддерживать только одну группу, а механизм иерархий появится в следующих фазах. В любом случае это будет, по-видимому, соответствовать потребностям рынка, поскольку единственная группа может содержать до нескольких сотен коммутаторов - значительно больше, чем понадобится подавляющему большинству сетей АТМ, которые могут появиться в течение одного или двух следующих лет.
Любой коммутатор следующего поколения, таким образом, должен не только поддерживать протокол P-NNI, чтобы обеспечить совместимость и масштабируемость АТМ-маршрутизации, но также должен обеспечивать простоту расширения протокола в отношении поэтапной реализации и изменения протокола в будущем. K счастью, за исключением некоторых новых спецификаций протокол P-NNI должен быть реализован главным образом в виде ПО и соответственно может легко заменяться в уже выпущенных устройствах. Это, кстати, является еще одним не очевидным, но важным фактом, поскольку АТМК следующего поколения должны обладать высокой производительностью сигнального процессора и процессора маршрутизации.
Многие современные конструкции АТМК оптимизированы только для компонента передачи ячеек, например в модуле коммутации при решении задачи обеспечения производительности АТМК. Однако, как отмечалось выше, в коммутаторе имеются два различных, но тесно связанных компонента: коммутация ячеек и обработка сигнальных процессов; задачи маршрутизации. Большинство сетевых протоколов, которые будут работать поверх АТМ, будут реализовывать механизм SVC. Это означает, что производительность определяется главным образом временем установления соединения SVC и соответствующими задержками.
Например, если интерактивные приложения, подобные telnet, работают поверх сети АТМ, то время реакции человека и ожидания ограничивают время, в течение которого требуемое соединение должно быть выполнено и данные переданы. Современные сети, работающие по технологии без установления соединения, создают впечатление мгновенной реакции. K несчастью, во многом структура сигнальных протоколов и протоколов маршрутизации АТМ не способствует установлению быстрого соединения. Например, современные процессоры могут наиболее быстро обрабатывать данные, выровненные на границе слова, в то время как сигнальный протокол АТМ, подтверждая свое происхождение от сетей общего доступа, является битовым протоколом, что значительно увеличивает нагрузки на процессор и задержки. Таким образом, протокол P-NNI, являясь наиболее сложным протоколом, ставит в то же время нестандартные и плохо формализованные требования к мощности процессора.
Следовательно, без интегрального выделенного высокопроизводительного процессора для выполнения сигнальных задач и задач маршрутизации крайне маловероятно достижение минимально требуемого уровня производительности (сотня или более вызовов в секунду) и задержек при установлении соединений в сотню или менее миллисекунд в расчете на один АТМК. Однако для снижения стоимости - такие высокопроизводительные процессоры и соответствующая им память и другие компоненты дороги - многие разработчики оборудования АТМ, особенно те, которые только приступают к реализации и приобретают опыт работы с протоколом UNI, выбрали дешевые низкоскоростные процессоры для своих коммутаторов. Более того, в некоторых устройствах используются внешние процессоры, в частности рабочие станции с невысокой производительностью и сомнительной надежностью.
Это примеры неоправданной экономии, поскольку производительность сети, созданной при помощи таких коммутаторов, быстро станет недостаточной, как только поверх этой сети начнет работать какой-либо сетевой протокол с широким использованием сигнальных режимов либо будет применен сложный протокол маршрутизации АТМ.
Существует ряд других дополнительных возможностей сигнального протокола, которыми должен будет обладать АТМК следующего поколения. Например, этот протокол будет использоваться не только для установки SVC, но и PVC. SVC будет доминировать в сетях АТМ, однако роль PVC важна, в частности, в случае двух оконечных систем (например, двух маршрутизаторов), которые должны быть постоянно соединены и не должны испытывать воздействия задержек при непрерывно устанавливающихся соединениях.
Дополнительные функции, реализуемые при помощи маршрутизации и сигнальных возможностей АТМ, состоят в применении механизма "soft PVC", когда соединение PVC устанавливается вручную при помощи двух UNI, но сигнальный механизм взаимодействия АТМК используется для установления соединения между начальным (src) АТМК и коммутатором назначения (dst). Такой режим не только значительно упрощает ручную конфигурацию, но также позволяет применять для "soft PVC" возможности маршрутизации с учетом QoS и динамической перемаршрутизации, свойственные протоколам АТМ-маршрутизации.
Весьма важна поддержка таких механизмов дублирования и повышения надежности, как динамическая перемаршрутизация вызовов в обход вышедших из строя АТМК или соединений, а также поддержка балансировки нагрузки по дублирующим соединениям.
По мере накопления опыта в определении значений параметров, подобных задержке при установлении соединения, такой механизм может быть использован для динамической перемаршрутизации уже установленных соединений в целях обеспечения перераспределения нагрузки в сети АТМ. Эти возможности явно не определены в спецификации P-NNI, и существует свобода для собственных решений фирм. Добавление таких возможностей к базовому уровню P-NNI позволит сетям АТМ приблизиться к надежности современных глобальных сетей, построенных на маршрутизаторах или по технологии мультиплексирования с разделением времени (TDM). А может быть, даже превзойти ее.
Очень важным сопутствующим компонентом АТМК является защитный барьер firewall. Он обеспечивается встроенными функциями фильтрации сигнальных запросов по заданным адресам АТМ или префиксам таких адресов (эти возможности можно рассматривать как эквиваленты аналогичных функций современных маршрутизаторов).
Проблемы защиты станут актуальными при увеличении масштабов сетей АТМ и по мере подключения их к сетям общего доступа. Контроль доступа - первый этап создания инфраструктуры безопасности сетей АТМ, основанной на технологии общедоступных ключей для идентификации доступа. Работы в этом направлении находятся на самой ранней стадии.
Для взаимодействия с общедоступными сетями будет помимо прочего необходима поддержка режима постоянного туннелирования (Permanent Virtual Path Tunnelling, или PVP Tunnelling). Этот механизм предназначен для взаимодействия сигнальных запросов между двумя АТМК, соединенными сетью общего доступа, не поддерживающей сигнального механизма (многие общедоступные сети не будут поддерживать эти возможности в обозримом будущем), причем требуется обеспечить работу какого-либо сетевого протокола поверх глобальной сети. Этот тип дополнительных нестандартных возможностей будет отличаться в каждой конкретной реализации протокола P-NNI.
Механизмы управления трафиком
После обсуждения вопросов, связанных с проблемами маршрутизации в сетях АТМ, перейдем к другому аспекту установления соединений и передачи ячеек - механизмам управления трафиком, позволяющим оконечным системам запрашивать конкретные значения QoS для соединений и обеспечивать эти значения. Возвращаясь к примеру, отметим, что первый этап установления соединения с заданной величиной QoS заключается в том, что вызывающая оконечная система должна передать всю информацию, необходимую для АТМК, с тем чтобы гарантировать заданную величину QoS. Оконечная система должна "рассказать" сети, какой тип соединения требуется. Это важно, поскольку АТМК должны различать типы запрашиваемых соединений - различные типы имеют существенно различающиеся характеристики трафика и QoS. Типы соединений, определенные спецификациями АТМ Forum, приведены в таблице (ранее Forum определял классы QoS, а не типы соединения, позже классы были переименованы в типы).
С каждым типом соединения связан набор определенных дескрипторов трафика. Наиболее распространенный тип соединения - VBR (Variable Bit Rate), который требует наибольших усилий по поддержке, например применения P-NNI. Весь набор характеристик трафика должен быть задан явно: средний и пиковый уровни скорости передачи ячеек, величина QoS, коэффициент потери ячеек, задержки и фазовых искажений. Комбинация этих параметров трафика и QoS составляет дескриптор трафика запрашиваемого соединения.
АТМК-инициатор соединения использует этот дескриптор трафика для взаимодействия с протоколом маршрутизации P-NNI, чтобы определить маршрут по сети АТМ, который сможет поддерживать предполагаемый уровень трафика при удовлетворении заданной величины QoS.
Для того чтобы сделать это, АТМК, выполняющий исходящее соединение (и каждый промежуточный), должен определить, сможет ли устанавливаемое соединение обеспечить требуемые характеристики, поскольку оно должно конкурировать за конечные разделяемые ресурсы, например буферное пространство АТМК. Определение ресурсов производится при помощи специальной функции, называемой CAC (Connection admission control). Функция CAC требуется для протокола P-NNI, но не описана в стандартах по ряду причин. Во-первых, эта функция является специфичной для каждого типа АТМК, и, во-вторых, она открыта для собственных решений фирм, поскольку удачный алгоритм CAC может обеспечить более эффективное использование сети, в то время как упрощенный алгоритм потребует меньших вычислительных затрат и соответственно увеличит скорость установления соединения.
Протокол P-NNI определяет, однако, так называемый общий CAC-алгоритм (GCAC - Generic CAC), который используется коммутаторами для выполнения "наилучшей оценки" по CAC-подобному алгоритму вдоль пути соединения от исходного до оконечного АТМК.
Алгоритмы CAC и GCAC являются только частью функций управления трафиком, которые взаимодействуют с протоколом P-NNI. Дескрипторы трафика также используются для того, чтобы упростить выбор вариантов возможного пути от исходного до конечного АТМК, наряду с такими дополнительными функциями, как балансировка нагрузки в пределах сети. В общем, детальный список алгоритмов для
P-NNI не является фиксированным, что обеспечивает свободу выбора для разработчиков оборудования АТМ. Качество управления трафиком будет важным аспектом при выборе конкретных реализаций P-NNI.
Сергей Турчин
ТИПЫ СОЕДИНЕНИЙ, ОПРЕДЕЛЕННЫЕ СПЕЦИФИКАЦИЯМИ ATM FORUM
+---------------------------+---------+----------------------------------------+
|Гарантированная величина | CBR |Постоянная скорость передачи. |
|полосы пропускания по | |Моделирование каналов, передача |
|запросу "Bandwidth on | |аудиоинформации |
|Demand" | | |
| |---------+----------------------------------------+
| | VBR |Переменная скорость передачи, полное |
| | |описание характеристик трафика. Real |
| | |Time VBR и non-Real Time VBR |
+---------------------------+---------+----------------------------------------+
|Сервис типа "лучшая | UBR |Неопределенная скорость передачи. |
|попытка" | |Отсутствие гарантий ("отправь и |
| | |молись") |
| |---------+----------------------------------------+
| | ABR |Определенная скорость передачи. |
| | |Отсутствуют количественные гарантии, но |
| | |в случае потери ячейки посылается |
| | |сигнал передающей системе |
+---------------------------+---------+----------------------------------------+
