Оригинал: Sally Floyd's web page at ICIR
http://www.icir.org/floyd/papers/wns2.pdf
Проект ns-3
Thomas R. Henderson and Sumit Roy
Department of Electrical Engineering
University of Washington
Seattle, Washington 98195–2500
Email: thenders, roy@ee.washington.edu |
Sally Floyd
ICSI Center for Internet Research
1947 Center Street, Suite 600
Berkeley, CA 94704
Email: floyd@icir.org |
George F. Riley
School of Electrical and
Computer Engineering
Georgia Institute of Technology
Atlanta, Georgia 30332–0250
Email: riley@ece.gatech.edu |
Перевод на русский Ерыгиной Т.
II Цели проекта ns-3
В данной секции представлены цели проекта ns-3, относящиеся к его функциональности. Несмотря на то, что планируется использовать в проекте многие модели ns-2, строгая обратная совместимость (возможность запускать скрипты ns-2 в ns-3 без изменения) не является целью проекта.
А. Обзор
Основная цель проекта – создать дискретный, использующий механизм событий симулятор для Интернет-систем, поддерживающий работу на уровнях 2-4 стека сетевых протоколов и предназначенный в первую очередь для исследований в области компьютерных сетей и использования в учебном процессе.
Другими целями проекта являются:
- проект должен иметь открытый код и возможность усовершенствования его сообществом разработчиков;
- симулятор должен распространяться бесплатно как проект с открытым кодом и предоставлять возможность дополнения другим свободно-распространяемым ПО для исследования работы компьютерных сетей;
- должна обеспечиваться поддержка масштабируемости, гибкости, модульности, эмулирования, все возможности должны быть хорошо документированы;
- модели, используемые в ядре симулятора необходимо протестировать и отладить;
- необходимо разработать набор базовых примеров моделирования.
В. Изменения в архитектуре симулятора
Несмотря на использование большого количества моделей проекта ns-2 (вплоть до обратной совместимости), планируется переработать архитектуру симулятора для обеспечения простоты его использования, масштабируемости (поддержка мультипроцессорности и 64-битных решений) и поддержки интеграции другого программного обеспечения. Процесс моделирования должен быть простым и обеспечивать реалистичные модели на разных уровнях абстракции. Симулятор должен позволять как моделирование сетей на основе протоколов IPv4 и IPv6, так и новых, исследовательских сетевых архитектур.
С. Взаимодействие с пользователем
Установка симулятора ns-3 проводится из исходного кода или готовых дистрибутивов для большинства популярных платформ: i386, x86_64, ppc, Linux, OS X (Darwin), Windows (эмулятор Cygwin), FreeBSD.
Симулятор по прежнему не имеет графического интерфейса, взаимодействие с пользователем происходит с помощью скриптов. Создание графического интерфейса для создания моделей возможно, но не входит в цели проекта. Результаты работы симулятора представлены в виде трассировочных, статистических, log-файлов и файлов для анимации модели. Трассировочные и log-файлы могут быть приведены в формат аниматор nam для обратной совместимости.
Ключевым вопросом является тип предоставляемого скриптового интерфейса. То, что скрипты OTcl необходимо заменить, не вызывает сомнений, но будут ли модели создаваться непосредственно на C++ или другим способом, еще не решено. Возможным решением может стать поддержка средства создания пользовательских интерфейсов (Simpliefied Wrapper and Interface Generator - swig), что даст пользователям возможность использовать для написания скриптов любой удобных им язык.
D. Интеграция
Авторы статьи считают одной из ключевых целей проекта ns-3 дать толчок к развитию другим проектам разработки свободного ПО, связанного с исследованием компьютерных сетей. В этой области поставлены такие задачи:
- обеспечить возможность расширения симулятора, интегрируя в него другие средства с открытым кодом;
- определить уровни абстракции и интерфейсы для переноса исходного кода в среду ns;
- создать интерфейсы, позволяющие пользователям легко переключаться между моделированием и эмуляцией работы сети.
E. Модели
Необходимо усовершенствование симулятора для поддержки все возрастающего количества беспроводных сетевых технологий, включая большое число вариантов стандарта IEEE, например, WiMax (802.16), и сотовых сервисов (GPRS, CDMA). На рисунке 1 показана таблица моделей, уже используемых в симуляторе ns-2, и моделей, планируемых к внедрению в симуляторе ns-3. Многие из планируемых моделей уже могут быть реализованы членами сообщества разработчиков. Новые модели будут созданы, отлажены и лицензированы по соответствующим правилам и внедрены в симулятор.
Рисунок 1. Модели, которые планируется реализовать в ns-3.
III. Реорганизация ядра.
А. Масштабирование
Одно из свойств симулятора ns-2, которое наиболее ценят его пользователи – это его масштабируемость. Процесс моделирования в ns-2 происходит последовательно, одновременно обрабатывается только одно событие на одном процессоре. Симулятор может обрабатывать сотни узлов, если модель достаточно абстрактна, но ресурсы памяти и процессора становятся «узким местом», если модель использует беспроводные протоколы или каналы с высокой пропускной способностью (например, 10 Гбит/сек). Для решения данной проблемы исследователи применяют различные методы, включая кэширование (проект «Staged NS (SNS)»), маршрутизацию «по требованию», разделение модели между кластерами (ns-2 gridkeeper и похожие структуры).
Факторов, ограничивающих масштабируемость, несколько, но основным из них является поддержка только одного процессора. Поэтому в симулятор ns-3 планируется включить поддержку параллельных и распределенных вычислений. Исследовательские группы в Georgia Tech разработали средство разработки параллельных сред моделирования Federated Simulation Developers Kit (FDK) и специальный подход к решению данной задачи, используемый в симуляторе GTNetS, который планируется использовать и в ns-3. Этот подход создает федеративную сетевую модель, состоящую из некоторого количества экземпляров симулятора, связанных с помощью специальной инфраструктуры периода выполнения (Runtime Infrastructure - RTI). Схема решения представлена на рисунке 2а.
Рисунок 2a. Концептуальная схема PDNS (в соответствии с [4])
Такое решение требует небольших затрат памяти для каждого из распределенных процессов моделирования, что позволяет избегать сложных решений, связанных с маршрутизацией внутри симулятора.
Для синхронизации используется достаточно консервативный подход. Ни один параллельный симулятор не сгенерирует событие, которое не должно было произойти согласно полученным ранее сообщениям. Это дает возможность избежать реализации функции сохранения состояния в существующем коде ns. Исследовательская группа PADS из Georgia Tech разработала ранее обширную библиотеку для поддержки ПО, реализующего возможности параллельного и распределенного моделирования. Данный программный продукт обеспечивает управление глобальным виртуальным временем, групповой передачей данных, буфером сообщений. Поддерживается различные типы взаимодействия, включая разделяемую память, Myrinet и сети TCP/IP, множество платформ. Используя данную библиотеку для распараллеливания ns, мы можем быстро изменить главный цикл обработки сообщений симулятора и ориентировать его на поддержку функций управления временем, необходимых для обеспечения безопасного генерирования событий каждым экземпляром симулятора.
Изменения функциональности, позволяющие вести распределенную обработку, могут быть разделены на 2 категории: изменения в обработке событий симулятором и расширение синтаксиса OTcl для описания моделей, в частности:
- ссылки на удаленный узел должны осуществляться по аналогии с сетевыми IP-адресом и номером порта. Ссылки на объект в памяти в распределенных вычислениях недопустимы;
- при выполнении маршрутизации пакетов может потребоваться информация, не представленная в данном экземпляре симулятора, поэтому необходимо обеспечить адекватное решение проблем маршрутизации в условиях недостаточной информации о сетевой топологии. Решением данной проблемы может послужить использование протоколов маршрутизации, например, OSPF, для вычисления маршрута. Однако этот подход приводит к сокращению возможностей масштабирования в связи с необходимостью содержать достаточно обширную таблицу маршрутизации в каждом узле. На данный момент симулятор ns-2 предлагает выбор между централизованной маршрутизацией, простыми моделями распределенной маршрутизации (векторы расстояний и состояния каналов) и специальной формой векторной маршрутизации NixRouting, позволяющей помнить и использовать полный маршрут от источника к пункту назначения в очень компактной форме;
- необходимо обеспечить некоторые методы деления пакета на части и его повторной сборки для передачи из одного экземпляра симулятора в другой;
- возможности распределенного моделирования не должны быть помехой при расчете простых моделей;
- сложность создания распределенной модели не должна превышать аналогичную сложность при создании простых моделей.
На рисунке 2б показаны результаты роста производительности моделирования при запуске PDNS на кластере под управлением ОС Linux, состоящем из 16 машин с восемью процессорами Pentium III XEON 550 МГц, 4 ГБ RAM.
Рисунок 2b. Масштабируемость PDNS (в соответствии с [5])
В. Другие изменения
Также предусматриваются следующие изменения:
1) Объектная структура. Средство моделирования компьютерных сетей, используемое сообществом исследователей в области компьютерных сетей, должно предоставлять возможность простого его расширения путем включения новых и модификаций существующих протоколов, типов маршрутизации. С этой целью ядро симулятора ns-2 имеет объектно-ориентированную С++ структуру и содержит большое количество классов для обеспечения базовой функциональности. К примеру, существует класс Queue, описывающий методы, общие для всех видов очередей. Подклассы объекта Queue реализуют различные диспциплины очередей, такие как DropTail и RED. Аналогично, класс TCP реализует базовую функциональность данного протокола, в то время как его подклассы предоставляют возможности использования различных вариантов протокола TCP. Гибкость может быть достигнута также использованием механизмов обратного вызова в различных точках процесса моделирования. Например, обратный вызов между сетевыми уровнями 2 и 3 может обеспечить функциональность файервола.
Однако, архитектура ns-2 требует изменений. В частности, разделяемая модель объектов С++/Otcl представляет некоторые проблемы. Во-первых, это малая распространенность и документированность языка OTcl, а также сложность отладки написанных с его помощью скриптов. Во-вторых, существуют ограничения на совместное использование объектов С++. Это затрудняет создание новых комбинаций объектов, исходя из чего было решено отказать от разделяемой объектной модели в пользу реализованной полностью на С++ структуры, контролируемой с помощью скриптов.
2) Реализм. Базовая структура симулятора должна достаточно точно соответствовать структуре реальных сетей и их элементов. При проектировании нового объекта, функции или интерфейса необходимо отдавать предпочтение той структуре, которая имеет место в действительности. Этот принцип существенно влияет на переносимость кода и возможность использования симулятора в образовании. Достижение этой цели возможно, например, при организации интерфейсов взаимодействия, используемых на практике, таких как «пользователь-ядро» (API для работы с сокетами) и «ядро-драйвер устройства».
3) Эффективность использования памяти. Симулятор должен поддерживать оба потока данных – полный и ограниченный. Другими словами, моделируемое приложение должно переслать 100,000 байтов данных удаленному узлу, но фактическое содержимое данных может быть достаточно абстрактным. На данный момент симулятор ns-2 оптимизирован для ограниченных потоков данных.
4) Трассировка. Для упрощения работы с моделями с большим количеством элементов и уменьшения объема регистрируемых и трассируемых событий, статистика моделирования должна гибко конфигурироваться пользователем. Некоторые возможности уже присутствуют в симуляторе ns-2: возможность трассирования только пакетов или слежение за определенным каналом. Более того, необходимо позволить пользователю определять тип регистрируемых данных, например, нужно ли регистрировать порты источника и приемника при исследовании протокола TCP.
5) Статистика. Упростить работу с симулятором позволит использование специальных объектов для сбора данных в процессе моделирования. Симулятор ns-2 поддерживает возможность интеграции таких объектов. Планируется расширить набор объектов гистограммами, графиками последовательности событий, объектами для поиска максимальных и минимальных значений, распределения вероятности.
6) Топология. Необходимо определить набор базовых топологий (звезда, дерево, случайная топология с заданного размера) с переменными параметрами, что позволит упростить процесс создания моделей.
7) Визуализация. Симулятор должен поддерживать какую-либо форму анимации любой части модели, что применимо при отладке и демонстрации работы сети. Средство анимации nam будет входить в состав симулятора, но его усовершенствование на данный момент не является целью проекта.
