Очевидными преимуществами, которые сулит развертывание таких сетей на практике, мы могли бы воспользоваться уже сегодня.., если бы не подводные камни, встречающиеся на пути любой новой технологии.
Решений проблемы нехватки пропускной способности в нелокальных сетях предложено множество. Приверженцы кардинальных подходов ратуют за полное обновление коммуникационной инфраструктуры, переход на оптоволоконные линии, замену протоколов. Этот путь, однако, сопряжен не только со значительными затратами, но и с низкими темпами внедрения: как известно, процесс стандартизации новых технологий и протоколов обычно растягивается на несколько лет, немало времени уходит и на их реализацию в коммерческих продуктах.
Специалисты, придерживающиеся более консервативных взглядов, не спешат обесценить сделанные ранее инвестиции. Они стремятся не радикально увеличить полосу пропускания, а повысить эффективность использования уже имеющихся ресурсов. В этом русле ведутся многочисленные разработки по совершенствованию алгоритмов маршрутизации, приданию коммутаторам более «интеллектуального облика» (коммутация третьего и четвертого уровней), реализации схем обработки трафика по приоритетам (QoS) и т.д.
Менее традиционной выглядит идея наделить сетевые приложения способностью самостоятельно определять протоколы, применяемые при передаче и приеме данных. Эта идея особенно заманчива в случае распространения на всю глобальную сеть. Если приложения начнут отправлять в сеть фрагменты исполняемого кода для управления работой промежуточных узлов, появится возможность настраивать функционирование сети под текущие потребности отдельных программ или пользователей. Этот подход, постепенно оформившийся в концепцию активных сетей (active networks), позволяет реализовать новые сетевые услуги и протоколы, минуя длительный процесс стандартизации.
У истоков
Концепция активных сетей представляет собой один из вариантов так называемых активных технологий, появившихся в середине 80-х гг. Первоначально областью их применения были операционные системы и языки программирования, а основным предназначением — обеспечение мобильности, эффективности или информационной безопасности. Хорошо известной реализацией активной технологии является язык PostScript, гарантирующий переносимость генерируемых файлов, но не их защиту. В области параллельных вычислений этот подход в начале 90-х гг. нашел выражение в форме активных сообщений, а для гетерогенных распределенных систем типичным примером может служить архитектура x-ядра.
Как показывает история развития активных технологий, около десяти лет сети оставались вне сферы их применения (в лучшем случае дело ограничивалось взаимодействием оконечных устройств, скажем, передачей кода между сервером и станцией-клиентом; технологии Web-кэширования и брандмауэры появились только в последние годы). Концепция активных сетей вводит активные технологии в самую сердцевину сети, распространяя их действие на маршрутизаторы, коммутаторы и серверы, расположенные в промежуточных узлах.
Первые работы в области активных сетей датированы 1994 г. Непосредственным стимулом их начала стали дискуссии, разгоревшиеся в ту пору среди сотрудников Управления перспективных исследований Министерства обороны США (DARPA) по поводу путей сокращения разрыва между возрастающими потребностями в пропускной способности и возможностями увеличения последней в существующих сетях с коммутацией пакетов. В 1995—1996 гг. интенсивные исследования в области активных сетей развернулись в нескольких американских университетах. Интерес к новому течению в технологиях глобальных сетей начинают проявлять и крупные фирмы, в частности BBN Technologies и Telcordia Technologies (бывшая Bellcore).
За прошедшие годы концепция активных сетей впитала в себя множество новаторских идей, фактически превратившись в обобщающее название группы различных технологий. Эти технологии объединяет стремление значительно увеличить интеллектуальность глобальных сетей, подняв ее на качественно новый уровень.
В традиционной среде с коммутацией пакетов обработка поступающего трафика маршрутизаторами в конечном счете сводится к пассивной пересылке данных из входных портов в выходные. Сетевые устройства не способны воспринимать смысл данных, генерируемых приложениями, так что те путешествуют по сети в своем первоначальном виде. Функция активного оборудования ограничивается анализом заголовков в сетях с коммутацией пакетов либо передачей и приемом сигнальной информации в сетях, ориентированных на установление соединений.
Концепция активных сетей предлагает принципиально иной взгляд на обработку трафика, которая должна учитывать запросы приложений и быстро меняющееся состояние сети. Функции динамического управления можно реализовать путем загрузки в сетевые устройства специального программного обеспечения с возможностью его оперативной модификации или перенастройки (отсюда еще одно название — программируемые сети).
Главная проблема здесь заключается в выборе конкретного способа доставки ПО в сетевые узлы. Основные варианты ее решения можно условно разбить на две большие группы. В первом случае загрузка ПО выполняется заранее, а поступающий трафик осуществляет лишь переключение на тот или иной сценарий обработки. Во втором исполняемые коды встраиваются непосредственно в пакеты данных.
По чужой указке
В качестве примера первого подхода рассмотрим архитектуру активных сетей, которая разработана в Технологическом институте шт. Джорджия не в последнюю очередь с ориентацией на построение самоорганизующихся кэшей в глобальных сетях.
Активные узлы и обработка пакетов. Для каждого промежуточного узла, называемого активным, определяется ограниченный набор операций с принимаемыми пакетами. При обработке трафика может использоваться информация о состоянии, которая хранится в данном узле и сама по себе не передается от узла к узлу (роль такой информации в традиционных сетях с коммутацией пакетов играют таблицы маршрутизации или таблицы коммутации виртуальных соединений).
Интерфейс между пользователем и сетью в этом случае организован простейшим образом. В заголовке каждого пакета содержится служебная информация (Active Processing Control Information, APCI), включающая идентификатор функции и дескриптор. Идентификатор определяет вызываемую функцию обработки, а дескриптор указывает на параметры состояния активного узла, которые должны использоваться в процессе обработки. Последовательность операций с поступившим пакетом выглядит так:
- определяется выходной порт (традиционным способом);
- если пакет содержит управляющую информацию, он переадресуется активному процессору, если нет — поступает в выходной порт;
- в соответствии с содержимым ACPI вызывается функция обработки и из информации о состоянии извлекаются требуемые параметры;
- если результатом выполнения функции является пакет, подлежащий передаче, производится обновление заголовка сетевого уровня и повторное вычисление APCI; одновременно обновляется информация о состоянии узла;
- пакет через выходной порт передается на следующий узел.
Наличие в активном узле предопределенного набора функций ограничивает гибкость данного подхода, зато позволяет оптимизировать процедуры обработки, реализовать их на аппаратном уровне и снять проблемы безопасности. Примерами функций, выполняемых по описанной схеме, могут служить буферизация пакетов и управление пропускной способностью выходных портов в соответствии с загрузкой каналов, упреждающее отбрасывание логически связанных порций данных при повреждении отдельных пакетов, дополнительное сжатие трафика до передачи его по перегруженному участку сети.
 |
| Рис. 1. Архитектура активного узла |
Типичная архитектура активного узла, оптимизированная для обработки сетевых перегрузок, показана на рис. 1. Переключатель перегрузки получает информацию от сетевых мониторов и обновляет таблицу маршрутов для нормального и перегруженного состояний сети. Путь, помеченный стрелкой «Нет», соответствует обычной транспортировке пакета в выходной порт, а стрелкой «Да» — обработке при высокой загруженности сети. В последнем случае пакет поступает на один из активных процессоров, где он преобразуется в новый формат (например, осуществляется разбиение на фрагменты, передаваемые отдельно). Внутреннее ядро маршрутизации обеспечивает высокоскоростную передачу пакетов между портами и активными процессорами.
В приведенном описании остались нераскрытыми два принципиальных момента, определяющих конкретную реализацию данной архитектуры: расположение полей APCI внутри пакета и способ их встраивания.
Положение служебной информации. Простейшее решение первой проблемы — размещение полей APCI в заголовке того уровня, на котором выполняется коммутация, — неприемлемо по двум причинам: в небольших пакетах типа ячеек ATM для дополнительной информации попросту нет свободного места, а кроме того, в этом случае не удовлетворяется требование обратной совместимости.
Более оправданным оказывается выделение «стандартной» позиции под APCI-записи настолько высоко в иерархии протоколов, чтобы ее наличие несильно сказалось на размере заголовков, и в то же время достаточно низко, чтобы доступ к ней могли без труда получить средства коммутации. Так, в сетях ATM поля APCI можно расположить непосредственно над заголовками адаптационного уровня (AAL).
Заметим, что такое решение гарантирует сосуществование активных и неактивных узлов в единой сетевой инфраструктуре. Пакеты, не содержащие управляющей информации, обрабатываются активными узлами согласно стандартным процедурам маршрутизации. И наоборот, дополнительное содержимое заголовков APCI-пакетов не распознается обычными узлами, так что они могут коммутироваться обычным образом.
Формирование пакетов. Основная трудность при реализации процедуры добавления полей APCI в отправляемые пакеты связана с тем, что в этих полях может присутствовать самая разнообразная информация (номер файлового блока, номер TCP-последовательности, идентификатор IP-дейтаграммы и т.д.). Эти сведения требуется свести воедино при сохранении многоуровневой схемы «одевания» пакетов.
Идеальный вариант предполагает, что заполнение полей APCI инициирует само приложение, поскольку оно лучше всего может определить необходимые процедуры обработки данных в активных узлах. В таком случае пользовательский интерфейс должен позволять приложению передавать поля APCI вниз по стеку протоколов. Не исключены также ситуации, когда выбор функции для активного процессора и запись ее идентификатора будут осуществляться протоколами нижележащих уровней (это означает, кстати, что для запуска в активной сети приложение не придется модифицировать!). По мере продвижения порции данных вниз по стеку протоколов на каждом уровне в APCI добавляется своя метка, которая может использоваться для распознавания структуры данных.
Все свое ношу с собой
Теперь обратимся ко второму подходу, используя в качестве иллюстрации архитектуру, предложенную сотрудниками Университета шт. Канзас и компании BBN Technologies в целях усовершенствования процедуры сетевого администрирования.
Капсулы и протоколы. В этом случае ключевая роль отводится пакетам данных со встроенными элементами кода (SmartPacket), именуемыми также пакетами-капсулами. В качестве языка для составления кода авторы проекта выбрали Java, одновременно перенеся в активные сети ряд принципов объектно-ориентированного программирования. Код, содержащийся внутри пакетов-капсул, фактически представляет собой Java-класс, который описывает методы для этого типа пользовательских данных. Каждый пакет содержит 128-разрядный идентификатор типа, определяющий протокол, к которому принадлежит пакет. (В архитектуре активных сетей понятие протокола претерпело неизбежную трансформацию и обозначает группу пакетов одного типа.)
Для ввода в обращение нового типа пакетов-капсул их генератор, в роли которого может выступать пользователь, приложение или маршрутизатор, направляет описание типа локальной программе-регистратору (Type Authority). Та, в свою очередь, идентифицирует источник описания, проверяет структуру присланного пакета и приводит описание нового типа пакетов к каноническому виду. Последний затем подвергается обычному хешированию и возвращается в виде уже упомянутого 128-разрядного идентификатора типа.
 |
| Рис. 2. Формат капсулы в системе ANTS |
Обработка пакетов и исполнение кода. После попадания капсулы в активный узел встроенный код извлекается из нее и запускается на выполнение. Выбор надлежащей среды исполнения (в одном узле может поддерживаться сразу несколько сред) осуществляется на основе идентификатора типа. Активный узел содержит набор ресурсов и примитивов, к которым может обращаться пользовательский код. Это позволяет, с одной стороны, обеспечить достаточную гибкость, а с другой, — ограничить степень влияния кода на поведение узла. В результате выполнения кода может произойти как модификация основного содержимого пакета, так и изменение работы узла в целом.
Базовая структура сети включает несколько активных узлов и один информационный сервер; на каждом из узлов и на сервере функционирует виртуальная Java-машина (JVM). Для обмена капсулами активные узлы встраивают их в UDP-пакеты. Роль информационного сервера заключается в хранении актуальных сведений о конфигурации сети. Именно от него в момент активизации сети узлы получают данные о соседних узлах.
Опуская детали реализации, перечислим компоненты управления, которые играют решающую роль в функционировании активной сети:
- менеджеры узлов (Node Managers) контролируют отдельные среды исполнения кода в активном узле и запускают другие компоненты управления;
- менеджер ресурсов (Resource Managers) обеспечивает доступ к ресурсам узла; для упрощения контроля за ресурсами обработка встроенного кода осуществляется по поточному механизму;
- программа-монитор (Resource Monitor) следит за использованием ресурсов отдельными потоками, а планировщик (Scheduler) формирует очередь заданий на выполнение и ограничивает число одновременно обрабатываемых потоков;
- менеджер маршрутизации (Routing Manager) генерирует пакеты-капсулы со встроенным кодом, определяющим модификацию, добавление или удаление отдельных записей таблиц маршрутизации на соседних узлах. Он же отвечает за стандартную маршрутизацию пакетов, если встроенный код не требует иного.
Функции перечисленных компонентов изменяются в зависимости от того, какой метод передачи кода используется в сети — интегрированный или дискретный. В первом случае код содержится в том же пакете, что и данные, и это лимитирует его длину, а также усложняет способ встраивания и извлечения. В дискретном варианте данные передаются в виде обычных дейтаграмм, а для транспортировки кода служат специальные управляющие пакеты, содержащие описания методов. Нетрудно заметить, что предельным случаем дискретного подхода является активная сеть с выбором одного способа обработки из нескольких, описанная в предыдущем разделе.
Использование байт-кода и классов Java для программирования сетевых узлов, несмотря на популярность данного языка, наличие удобных средств разработки и разнообразие возможных приложений, нельзя признать идеальным выбором. Применение в активном узле интерпретатора байт-кода отрицательно сказывается на производительности. Кроме того, этот вариант ограничивает возможности контроля за использованием ресурсов. В результате вместо поддержки разных уровней качества сервиса (QoS) приходится ограничиваться реализацией базовых функций сетевой обработки.
Указанные недостатки, особенно существенные, когда речь идет об управлении сетями, заставили специалистов BBN Technologies создать собственный инструментарий для обработки капсул в активной сети. Ими предложены два специальных языка программирования: высокоуровневый Sprocket со встроенными средствами поддержки процедур администрирования и аналог ассемблера Spanner для CISC-процессоров, в который компилируется исходный Sprocket-код. Сетевой интерфейс реализован в виде виртуальной машины Spanner, запускаемой на активном узле. Использование Spanner позволяет создавать управляющие утилиты размером до 1 Кбайт, которые легко встраиваются в состав пакетов-капсул. Помимо этого, переход на специальные языки программирования в значительной мере помог решить проблему защиты сетевых ресурсов.
Другой выход из положения найден в университете шт. Арканзас, где разработана специальная версия JVM, именуемая Joust и поддерживающая абстракции нижнего уровня для планирования административных процедур в реальном времени.
Наконец, еще одним способом преодоления ограничений Java-реализации может служить применение комбинированного подхода.
На стыке двух миров
Как показывает анализ двух групп алгоритмов доставки управляющего кода в активные узлы, первый подход страдает от недостаточной гибкости, зато упрощает контроль за корректностью изменений, вносимых в работу узла, и к тому же практически не замедляет передачу пакетов. Второй вариант предоставляет разработчикам полную свободу в изменении функциональности узлов, однако сопряжен с существенными временными затратами на интерпретацию кода и чреват нарушениями в работе сети. В этой связи на программы, загружаемые в узлы в процессе передачи трафика, приходится накладывать определенные ограничения.
Для реализации таких ограничений можно использовать механизм контроля за состоянием активного узла. Сетевой API-интерфейс должен предусматривать возможность установки состояния, доступа к параметрам состояния, заданного другими приложениями (пакетами), и защиты состояния от несанкционированного изменения. Кроме того, для минимизации нежелательных эффектов, которые могут быть вызваны исполнением загруженного кода, устанавливаются предельное время выполнения кода, максимальный объем выделяемой ему памяти, доступная часть суммарной полосы пропускания канала и ряд других параметров.
Отдельный вопрос связан со степенью воздействия изменений, внесенных данным пакетом в состояние узла, на обработку других частей трафика. Простейший вариант предполагает, что новые процедуры обработки распространяются на все последующие пакеты, пока не будет изменено состояние узла. Другая крайность сводится к тому, что каждый пакет регулирует только собственную обработку. Рациональное решение находится посередине: пакет, задающий состояние активного узла, определяет операции над группой пакетов одного типа.
Попытка соединить лучшие качества разных способов доставки управляющего кода в активные узлы была предпринята сотрудниками Университета шт. Пенсильвания и компании Telcordia. В рамках совместного проекта SwitchWare этими организациями предложен специальный язык для активных сетей PLAN (Programming Language for Active Networks). Основная задача проекта заключается в создании программного коммутатора, допускающего загрузку ПО для изменения параметров соединений.
В тестовой сети PLANet, где используется язык PLAN, циркулируют как пакеты со встроенными элементами исполняемого кода, так и небольшие программы, заранее загружаемые в коммутаторы (switchlets). Эти программы предоставляют управляющим утилитам, передаваемым по сети, доступ к базовым функциональным возможностям, которые не удается реализовать непосредственно в мобильном коде (вроде обеспечения актуальности таблиц маршрутизации). Кроме того, разделение активного кода между узлами и капсулами позволяет удержать размер последних в разумных пределах.
Язык PLAN поддерживает набор базовых примитивов, составной код и вызов программ, загружаемых в коммутаторы. Для повышения степени защищенности сети и улучшения контроля за использованием ресурсов пакетам-капсулам запрещено изменять состояние активных узлов.
К новым услугам
Начало работ в области активных сетей сразу же поставило вопрос о преимуществах, которые сулит практическая реализация этой концепции. Основной ответ на него сводится к тому, что появление активных сетей не только повысит эффективность работы существующих приложений, но и вызовет к жизни совершенно новые типы услуг. С точки зрения провайдеров, заметно сократится цикл их внедрения в имеющиеся сети, пользователи получат инструментарий для гибкой настройки сетевого сервиса в соответствии с индивидуальными потребностями, а исследователи смогут поэкспериментировать с новыми услугами, практически не влияя на работу существующих сетей. Для иллюстрации открывающихся возможностей рассмотрим два примера, ориентированных на конкретные приложения.
 |
| Рис. 3. Маршрутизация капсул в активной сети |
Технология активных сетей позволит реализовать алгоритм адаптивного Web-кэширования, который учитывает потребности конкретного пользователя. Во-первых, специальный протокол мог бы выполнять кэширование сведений о текущих котировках по отдельным компаниям, так что вероятность попадания в кэш приблизилась бы к единице независимо от содержания конкретного запроса. Во-вторых, актуальность содержимого кэша (скажем, котировки 15-минутной давности или итоговые значения по результатам сессии) определялась бы самим пользователем.
Другой пример относится к области онлайновых аукционов, завоевывающих популярность в последнее время. Сетевые задержки приводят к тому, что в момент получения клиентом данных о текущей цене лота, отправленных сервером в ответ на запрос, эта информация зачастую оказывается устаревшей. Поэтому, в отличие от традиционных торгов, в период заметной активности участников серверу приходится отвергать большую часть поступающих предложений.
Решение этой проблемы состоит в фильтрации заведомо неподходящих предложений цены в самой сети, до их попадания на сервер. В такой схеме в случае превышения порогового значения нагрузки сервер должен активизировать фильтры на узлах активной сети, периодически передавая им самую свежую информацию о стоимости выставленных лотов. Отбрасывание неподходящих предложений и уведомление их авторов осуществляют эти же узлы. В результате ресурсы сервера освободятся для более производительной обработки актуальных предложений и одновременно уменьшится нагрузка на примыкающие сетевые каналы.
Приведенные примеры, иллюстрируя преимущества технологии активных сетей, позволяют сделать один немаловажный вывод. Традиционные метрики сетевой производительности (пропускная способность, задержки передачи) апеллируют к параметрам коммуникационной инфраструктуры. Для пользователя же интерес представляет только быстродействие запущенного приложения, которое далеко не всегда коррелирует с производительностью сети. Работа алгоритмов активной сети способна привести к уменьшению числа принятых пакетов или обслуженных сервером запросов (как в случае с электронным аукционом) либо к росту задержек в отдельных соединениях. Тем не менее для пользователя эти эффекты могут выразиться в ускорении работы приложений (из-за меньших требований к пропускной способности на периферии сети, снижения загруженности каналов и т.д.). Эксперименты с сервером электронного аукциона, выполненные сотрудниками MIT, показали, что делегирование части функций активным узлам приводит к росту как числа обработанных предложений о покупке лота, так и общего количества лотов, продаваемых в единицу времени. (Заметим, однако, что этот рост производительности достигнут ценой более интенсивного использования сетевых ресурсов, что может негативно отразиться на других видах трафика в той же сети.)
Существенно и то, что размер выигрыша в производительности напрямую зависит от того места, куда переносится часть серверных функций. В обоих примерах активные узлы должны быть расположены так, чтобы обслужить максимальное число клиентских запросов. Размещение фильтров вблизи узкого места сети позволяет снизить задержки передачи и потери пакетов из-за перегруженности сети. Это означает, что местоположение узлов, на которые возлагаются задачи интенсивной интеллектуальной обработки трафика, должно зависеть не только от специфики приложения, но и от динамично меняющегося состояния сети.
В знакомом окружении
Появление активных сетей, развернутых поверх существующих корпоративных коммуникационных инфраструктур или сетей провайдеров, должно изменить и работу традиционных приложений. Использование пакетов со встроенным кодом позволит автоматизировать процедуры шифрования и аутентификации (например, первый пакет может содержать информацию о шифровании, относящуюся ко всему потоку). Привнесение в сеть дополнительных интеллектуальных функций открывает новые возможности и в сфере сетевого администрирования, позволяя реализовать интеллектуальные схемы диагностики нарушений функционирования сети.
По-иному удастся реализовать и алгоритмы приоритезации трафика (QoS), преодолев недостатки традиционных схем, когда отправитель должен подстраиваться под изменившиеся условия работы сети (резко возросшую перегрузку). На распознавание новых условий, реагирование и отправку «адаптированных» данных уходит довольно много времени, в течение которого имеют место неконтролируемые потери пакетов. Интеллектуальная обработка трафика на промежуточных узлах позволит заметно сократить эти потери.
Среди сетевых приложений, функционирование которых в активных сетях может оказаться более эффективным, упомянем также многоадресную рассылку пакетов и передачу аудио- и видеопотоков в реальном времени.
Слишком хорошо, чтобы быть правдой?
Изучение появившихся англоязычных публикаций может породить иллюзию, будто концепция активных сетей есть своего рода волшебный камень, способный превратить в оптоволоконное «золото» километры «презренной меди». В действительности все обстоит не столь гладко и, как свидетельствует новейшая история развития технологий, всякое достижение имеет свои оборотные стороны. Активные сети — не исключение. Ситуация осложняется тем, что рассматриваемая концепция еще слишком молода и количество нерешенных проблем значительно превосходит число вопросов, ответы на которые уже получены.
Практическое применение технологии активных сетей встречает серьезные препятствия в сфере защиты данных, особенно если программное обеспечение в сетевые узлы загружают сами пользователи. Эффективность активных сетей тем выше, чем шире доступ мобильного ПО к сетевым ресурсам. Однако указанное обстоятельство уменьшает их надежность: код, содержащий ошибки или написанный хакером, способен парализовать работу всей сети. Это заставляет принимать меры, ограничивающие влияние дефектного кода на работу сети и его взаимодействие с другими сетевыми программными средствами.
Обработка принимаемого кода в сетевых узлах, особенно с учетом специальных мер в области защиты, снижает производительность маршрутизаторов. Как показало тестирование системы PLANet, обработка пакетов-капсул приводит к существенному возрастанию задержек. Другими словами, повышение эффективности использования имеющейся полосы пропускания станет ощутимым только после наращивания вычислительных ресурсов сетевых узлов, прежде всего памяти и каналов ввода/вывода.
Еще один немаловажный фактор — совместимость. Как уже говорилось, использование принципов активных сетей позволяет реализовать новые услуги без длительной процедуры согласования и принятия стандартов. Тем не менее представлять дело так, будто при построении активных сетей можно вообще обойтись без стандартов, было бы неверно. Продукты разных поставщиков должны взаимодействовать друг с другом. Путь к обеспечению такого взаимодействия лежит через выработку универсальных интерфейсов прикладного программирования (API), используемых при создании и интерпретации передаваемого кода. Появление API-интерфейсов, поддерживаемых разными платформами, позволит уменьшить размер кода, что благоприятно скажется на общей производительности сети. Наличие API-интерфейсов необходимо и для совместимости с узлами, не поддерживающими новую технологию: пакеты без встроенного кода будут обрабатываться обычным образом.
Изменение способов управления работой сетевых узлов требует установки на них специального системного ПО. Традиционные ОС вряд ли подойдут на эту роль, поскольку они создавались с ориентацией на вычислительные задачи. Операционные системы, управляющие функционированием активных узлов, должны быть оптимизированы для выполнения преимущественно коммуникационных функций. В качестве первых представителей ОС такого класса можно назвать Janos и Scout.
Информационная безопасность, производительность, взаимодействие — этим, к сожалению, не исчерпывается перечень барьеров, сдерживающих развертывание активных сетей. Предоставление нескольким пользователям возможности управлять работой сети означает, что в один узел могут поступить пакеты, требующие изменения его функционирования в противоположных направлениях. Способы разрешения подобных конфликтных ситуаций (скорее всего, на основе схемы приоритетов) нуждаются в дальнейшей проработке.
Передача по сети пакетов-капсул может натолкнуться на противодействие со стороны брандмауэров, а это сведет на нет все преимущества новой технологии. К этой же сфере относится более общая задача выработки эффективного метода транспортировки мобильного кода по активной сети.
Взгляд в будущее
За без малого пять лет своего существования технологии активных сетей проделали путь от абстрактной идеи до тестовых испытаний. В прошлом году были опубликованы данные тестирования параметров активных сетей, построенных в корпорации BBN и ряде университетов. Эти первые опыты (пусть даже проведенные в лабораторных условиях) дали обнадеживающие результаты.
Что же дальше? Судя по активности существующих исследовательских групп (см. врезку «Современные проекты»), перечисленные выше проблемы могут быть решены в ближайшие два—три года. Выбор в пользу языка Java практически решает вопрос стандартизации программных интерфейсов. Нет оснований опасаться и недостатка встраиваемых приложений: первые же практические реализации активных сетей станут мощным стимулом как для поставщиков сетевых услуг, так и для независимых фирм-разработчиков.
Остается едва ли не самый серьезный вопрос — экономический. Несмотря на то что активные сети позволяют сохранить предыдущие вложения в коммуникационную инфраструктуру, сетевое оборудование и программное обеспечение, их внедрение невозможно без финансовых затрат. К сожалению, автору пока не удалось обнаружить каких-либо оценок требуемых инвестиций. По-видимому, их размер станет главным противовесом многочисленным достоинствам новой технологии.
Завершая рассказ о перспективах, которые открываются перед телекоммуникационной индустрией благодаря использованию технологии активных сетей, упомянем о совсем уж экзотической возможности обмена служебной информацией между пакетами, путешествующими по сети. При наличии в активном узле специального кэша пакет-капсула может записать в него те или иные данные, а пакеты, передаваемые следом, с помощью встроенного Java-кода считать содержимое кэша и использовать его для изменения процедуры последующей обработки трафика. Сегодня еще не ясно, какими приложениями будет востребована описанная возможность. Тем не менее она недвусмысленно свидетельствует о том, что концепция активных сетей со временем может кардинально изменить устоявшиеся взгляды на принципы сетевой обработки.
| Современные проекты |
Исследования в области активных сетей ведутся в нескольких организациях, главным образом находящихся в США. Значительная их часть ориентирована на сферу сетевого администрирования. Помимо описанных в обзоре исследований, которые осуществляются в Технологическом институте шт. Джорджия, к этой же области относятся проекты Network Management by Delegation Paradigm (Колумбийский университет) и Darwin Project (Университет Карнеги-Меллона). В проекте Netscript Колумбийского университета для усовершенствования задач управления используется одноименный язык описания сценариев. Программирование составных процедур обработки трафика из базового набора ведется на Java. Продемонстрированы возможности нового подхода при создании динамических межсетевых экранов и специализированных функций маршрутизации. Проект по поддержке активной сигнализации, стартовавший в Университете шт. Южная Каролина, направлен на организацию новых сетевых сервисов для целей администрирования. В связи с этим их инициация осуществляется специальными управляющими агентами, а не приложениями конечных пользователей, генерирующими основной сетевой трафик. В Технологическом институте шт. Джорджия ведутся также работы в области динамических сетевых сервисов, формируемых из набора базовых служб. Предложенная его сотрудниками усеченная модель программирования Liane ограничивает гибкость активной сети, зато позволяет авторам кода практически не заботиться о ее защите. В настоящее время рассматривается возможность применения модели Liane в системах многоадресной передачи. На повышение защищенности активной сети и ужесточение контроля за использованием ресурсов отдельных узлов нацелена также архитектура Secure Active Network Environment (SANE), разрабатываемая в Университете шт. Пенсильвания. Отметим еще группу исследователей из Колумбийского университета, которые совместно со своими коллегами из других организаций создают интеллектуальные средства управления соединениями и поддержки качества сервиса в сетях ATM. В предложенной ими архитектуре xbind используются программы на языке C и набор управляющих примитивов, поставляемых производителями ATM-коммутаторов. Сетевой интерфейс, поддерживающий спецификации брокеров объектных запросов CORBA, допускает модификацию состояния активного узла. Вообще, развитие технологий активных сетей потребовало перенести в сетевую индустрию множество идей как из системного, так и прикладного объектно-ориентированного программирования. Скажем, разработчикам архитектуры Liquid Software (Университет шт. Аризона) для всеобъемлющего управления локальными ресурсами и поддержания высокой производительности пришлось создать специальную ОС активного узла Scout. Кроме того, ими же предпринята попытка преодолеть проблему невысокой производительности, которую влечет за собой использование кода на Java. Перед исполнением он транслируется в код на C, так что в активном узле можно не устанавливать интерпретатор байт-кода, а запускать высокопроизводительный компилятор с языка C. Сотрудники Университета Сассекса (проект Safetynet) разрабатывают язык программирования, ориентированный на описание процедур передачи пакетов. Построенная ими модель программирования, с одной стороны, позволяет поддерживать работоспособность активной сети, а с другой — накладывает жесткие ограничения на информационную безопасность и выделение ресурсов. В MIT предложена технология Active IP Option, распространяющая возможности механизма IP Options на активные сети и, прежде всего, определяющая встраивание фрагментов кода в дейтаграммы. Сам код можно написать на произвольном языке либо перед отправкой пакета выдать маршрутизатору запрос о поддерживаемых языках. В тестовой реализации новой технологии в качестве языка программирования использован TCL, на активных узлах устанавливаются его интерпретаторы. Еще один вариант передачи кода вместе с данными — архитектура M0 — разработан в Калифорнийском (г. Беркли) и Цюрихском университетах. Для обмена информацией между активными узлами используются мессенджеры, аналогичные капсулам или интеллектуальным пакетам (SmartPacket) в других архитектурах. Для написания кода мессенджеров выбран язык M0, унаследовавший основные свойства от PostScript. В настоящее время обеспечена поддержка передачи мессенджеров в дейтаграммах UDP, в кадрах Ethernet и в данных, транспортируемых по последовательным линиям. Инструментарий Active Node Transfer Systems (ANTS), созданный сотрудниками Массачусетского технологического института, использует пакеты-капсулы и виртуальную Java-машину для выполнения методов, обеспечивающих декодирование и интерпретацию содержащегося в капсулах байт-кода. При этом капсулы могут устанавливать состояние узла и вызывать классы, определенные другими капсулами. Функция передачи кода в активный узел возложена на первый пакет; все последующие пакеты могут использовать указанный код, но сами по себе содержат только данные. На самом нижнем уровне архитектуры ANTS допускается передача кода любым пакетом. Однако в этом случае возможности кода ограничиваются выбором метода для обработки данных. |
| Дополнительные источники информации |
Приведенные ниже Web-адреса позволят познакомиться с избранными работами в области активных сетей, а также найти гиперссылки для получения более детальной информации. DARPA: http://www.darpa.mil/ito/research/anets/index.html Проект в Технологическом институте шт. Джорджия: http://www.cc.gatech.еdu/projects/canes/ (содержит множество других ссылок) Проект ANTS (MIT): http://www.tns.lcs.mit.edu/activeware Проект Liquid Software: ftp.cs.arizona.edu/xkernel/Papers/tr96-11.ps Проект Netscript: http://www.cs.columbia.edu/dcc/netscript Проект Smart Packets (компания BBN Technologies): http://www.net-tech.bbn.com/smtpkts/smtpkts-index.html Проект SwitchWare (Университет шт. Пенсильвания совместно с компанией Bellcore): http://www.cis.upenn.edu/~switchware Проект в Вашингтонском университете: http://www.arl.wustl.edu/arl/projects/ann/ann.html Кроме того, заслуживают упоминания два обзора по активным сетям, опубликованные в «IEEE Communications Magazine» (№ 1 за 1996 г. и № 10 за 1998 г.), а также специальный выпуск журнала "IEEE Network" (July-August, 1998), целиком посвященный данной тематике. |