ММТССиПД_ns2_метода

логические функции, но такое разделение позволяет некоторым реализациям сетевых компонентов, созданных пользователем (не входящих в ядро ns2),

использовать особые виды планировщика. Календарь в планировщике событий модельного времени установлен по умолчанию.

Рисунок 3.4. Процедура создания события сетевым объектом

Выбор особого вида планировщика осуществляется:

. . .

set ns [new Simulator]

$ns use-scheduler Heap

. . .

Планировщик событий реального времени используется для эмуляции,

когда пакет моделирования взаимодействует с реальной сетью. В настоящее время такой вид эмуляции находится в стадии разработки, хотя экспериментальная версия уже действует в ns2.

Другое важное использование планировщика событий – это планирование событий моделирования, такие как, например, старт приложения FTP, окончание моделирования, генерация сценария моделирования до запуска самого моделирования и т.д. Сам объект

«планировщик событий» имеет планировочные частные функции, такие как at time "string" , которые в определенное время моделирования (time) создают специальные события, называемые at-событиями (AtEvent). AtEvent –

33

является классом-потомком класса “Event”, который имеет дополнительную переменную для присваивания заданной строки (string). И at-событие внутри планировщика событий обрабатывается так же, как и обычное событие

(связанное с передачей пакетов).

Когда начинается моделирование и наступает время at-события,

заданное по графику в очереди событий, at-событие поступает на обработчик at-события, который создается только один раз. Он обрабатывает все at-

события, а OTcl выполняет команду, определенную в поле string at-события.

Тогда предыдущий пример с добавкой at-события будет иметь вид:

. . .

set ns [new Simulator] $ns use-scheduler Heap

$ns at 300.5 "complete_sim"

. . .

proc complete_sim {} {

. . .

}

At time "string" является частной функцией объекта Simulator (set ns [new Simulator]). Объект Simulator действует как пользовательский интерфейс, который вызывает частные функции сетевых объектов или объектов планировщика, которые в свою очередь и выполняют всю «работу».

Ниже приведен частичный список и краткое описание частных функций объекта Simulator, которые взаимодействуют с частными функциями планировщика:

Simulator instproc now	# возвращает текущее время в планировщике
Simulator instproc at args	# исполнение расписания кода в определенное время
Simulator instproc at-now args	# исполнение расписания кода немедленно
Simulator instproc after n args	# исполнение расписания кода по истечении n секунд
Simulator instproc run args	# запустить планировщик
Simulator instproc halt	# остановить (приостановить) планировщик

34

3.3.2. ОСНОВНЫЕ СЕТЕВЫЕ ОБЪЕКТЫ NS2

Ns2 имеет свою иерархию сетевых компонентов (рисунок 3.5). На

рисунке показана частичная иерархия класса OTcl в ns2.

35

Рис. 3.5 Основные сетевые объекты, входящие в состав ns2

36

Основу иерархии составляет класс TclObject, который является суперклассом всех объектов библиотек OTcl (планировщик, сетевые компоненты, таймеры и д.р., включая и связанные с визуализатором «nam»

объекты). В качестве класса, являющегося базовым классом для TclObject,

служит класс NsObject – суперкласс для всех основных сетевых объектов компонентной модели, обрабатывающих пакеты и представляющих собой сложные сетевые объекты такие, как узлы и звенья. Далее основные сетевые компоненты делятся на два подкласса: Соединители (Connector) и

классификаторы (Classifier) по числу возможных выходных информационных каналов. Основные сетевые объекты, имеющие один выходной информационный канал, относятся к классу Соединителей, а

коммутационные объекты, которые имеют несколько выходных информационных каналов – класс Классификаторов.

Объекты, показанные на рис. 3.5 являются простыми, из них состоят сложные объекты, основные из которых: узлы и звенья.

Узлы

Узел – сложный сетевой объект, состоящий из объекта входа, и

классификаторов. В ns2 существует два типа узлов. Уникастный узел имеет классификатор адресов, который осуществляет уникастную маршрутизацию

(определяется только один получатель в сети), и классификатор портов

(рисунок 3.6).

37

Приложение

Агент

Приложение

Агент

Классификатор порта

Классификатор адреса

Звено

Звено

Вход узла

Звено Звено

Рис. 3.6. Структура уникастного узла

Мультикастовый узел (рис. 3.7.), кроме того, имеет классификатор,

который отличает мультикастовые пакеты от уникастных, и мультикастовый классификатор, который осуществляет мультикастовую маршрутизацию

(определяется группа получателей, возможно, расположенных в различных местах объединенной сети). По умолчанию в ns2 используются уникастные узлы. Для создания мультикастового узла пользователем после создания объекта планировщика подробно описываются в скрипте OTcl все узлы,

которые будут мультикастовыми. После определения типа узла пользователем также выбирается определенный протокол маршрутизации,

отличный от установленного по умолчанию.

38

Приложение

Агент

Приложение

Классификатор

Агент

порта

Классификатор

адреса

Звено

Звено

Вход узла

Мультикастовый

классификатор

Рис. 3.7. Структура мультикастового узла

Звено

Звено (link) – другой важный сложный (составной) объект в ns2. Когда

пользователь создает звено, используя частную функцию duplex-link объекта

Simulator, создаются два симплексных звена в двух направлениях (рис. 3.8).

n1	Звено	n2

Симплексное звено

Симплексное звено

Рис. 3.8. Дуплексное звено

39

Рис. 3.9. Симплексное звено

Симплексное звено, в свою очередь, изображено на рис. 3.9. Выходная очередь с узла реализована как часть симплексного звена. Пакеты после очереди поступают на объект «Задержка», который моделирует задержку в звене, а пакеты, отброшенные в очереди, посылаются на Нулевой агент и стираются там. Объект TTL (Time-To-Live) считает параметры времени жизни для каждого принятого пакета и обновляет поле TTL в заголовке пакета.

Объекты трассировки

Действия в ns2 отслеживаются в симплексных звеньях. Если модель ориентирована на трассировку событий в сети (в тексте программы описано использование команды $ns trace-all файл или $ns namtrace-all файл, где файл

– это выходной файл для записи трассировки событий), звенья, созданные после такой команды будут иметь в своем составе объекты трассировки (рис. 3.10.).

EnqT (enqueue tracing) – трассировочный объект постановки в очередь

DeqT (dequeue tracing) – трассировочный объект вывода из очереди

DrpT (drop tracing) – трассировочный объект отбрасывания пакетов

RecvT (receive tracing) – трассировочный объект принятых узлом пакетов

Рис. 3.10. Звено с объектами трассировки

Также пользователем может быть создан объект трассировки типа type

между заданным src (узлом-источником) и dst (узлом назначения), используя команду create-trace {type file src dst}. Когда пакет достигает одного из трассировочных объектов (EnqT, DeqT, DrpT и RecvT), то соответствующее событие записывается в специальный трейс-файл, причем это не занимает никакого времени моделирования, а пакет отправляется на следующий объект.

Мониторинг очередей

40

Объекты трассировки предназначены для того, чтобы записывать время прибытия пакетов в то место, где они расположены. Несмотря на то, что пользователь получает достаточно большой объем информации из трейс-

файла, ему может быть нужна информация о том, что происходит внутри некоторых видов очередей. Например, пользователю, заинтересованному в поведении очереди RED (Random Early Detection), могут понадобиться измерения динамики изменения среднего размера очереди и текущего размера очереди (т.е. нужен мониторинг очереди).

Мониторинг очереди может быть осуществлен при использовании объектов мониторинга очереди и объектов слежки за очередью (см. рис. 3.11.).

SnoopQ/In – входной объект слежки за очередью

SnoopQ/Out – выходной объект слежки за очередью

SnoopQ/Drop – объект слежки за отбрасываемыми пакетами в очереди

Рис. 3.11. Звено с объектами мониторинга очереди

Когда прибывает пакет, объект слежки за очередью извещает диспетчера очереди об этом событии. Используя эту информацию, диспетчер очереди осуществляет мониторинг очереди.

Объекты слежки очереди могут использоваться одновременно с объектами трассировки.

3.3.3. ПАКЕТ

В ns2 пакет состоит из набора заголовков и иногда поля данных.

Формат заголовка пакета задается, когда создается объект Simulator, где описан набор всех существующих (или используемых) заголовков: общий

41

заголовок, который обычно используется всеми объектами, IP-заголовок, TCP-заголовок, RTP-заголовок (UDP в ns2 использует RTP-заголовок) и

трейс-заголовок (см. рис. 3.12).

Рис. 3.12. Структура пакета

Также записаны сдвиги каждого заголовка в пакете. Это значит, что,

неважно, используется или нет, тот или иной заголовок, стек заголовков,

создаваемый агентом, состоит из всех существующих заголовков, а сетевой объект может получить доступ к любому заголовку в стеке, используя соответствующую величину сдвига.

Обычно пакет имеет только стек заголовков (а поле данных отсутствует). Хотя пакет может переносить и реальную информацию (от приложения), заполнив при этом поле данных, но практически все реализации приложений и агентов не поддерживают эту функцию, потому что нет особого смысла переносить данные по моделируемой сети. Но если пользователю необходимо реализовать приложение, которое взаимодействует с приложением реальной сети, нужно внести изменения в реализацию агента,

поверх которого работает данное приложение. Другой возможный вариант состоит в создании нового заголовка для приложения и изменении агента.

Агент должен записывать данные, принятые от приложения в новый заголовок.

4.МОДЕЛИРОВАНИЕ СЕТЕЙ IP НА NS2

4.1.Этапы моделирования сетей на ns2

42