Мультисервисные сети2

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

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

осуществляется мониторинг очередей [3].

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

(рис. 16.13).

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

На рис. 16.13:

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

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

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

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

Для добавления объектов мониторинга очереди в тиклет модели необходимо добавить строку

set qmon [$ns monitor-queue $n2 $n3 [open qm.out w] 0.1]

Объект monitor-queue имеет четыре параметра: первые два определяют звено, за которым производится слежение (узел-узел), третий параметр указывает файл, куда будет производиться запись, последний показывает, как часто снимаются показания. В приведенном примере снимаются показания на линии между узлами n2 и n3 и записываются в файл qm.out через каждые 0,1 с.

Выходной файл содержит 11 столбцов:

1.Время.

2.Входной и выходной узлы, задающие очередь (2-3-й столбцы).

4.Размер очереди в байтах (атрибут size_ объекта monitorqueue).

5.Размер очереди в пакетах (атрибут pkt_).

6.Количество пришедших пакетов (атрибут parrivals_).

7.Количество ушедших из звена пакетов (атрибут pdepartures_).

8.Количество пакетов, выброшенных из очереди (атрибут pdrops_).

9.Количество пришедших байтов (атрибут barrivals_).

10.Количество ушедших из звена байтов (атрибут bdepartures_).

11.Количество байтов, выброшенных из очереди (атрибут bdrops_).

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

16.2.6. Абстракции транспортного уровня – агенты

Чтобы определить соединение в NS2, необходимо создать два агента: агент-передатчик и агент-приемник [3, 5, 6].

Передатчик может вести себя различным образом в зависимости от используемого в симуляции протокола транспортного уровня. Соответственно, в системе NS2 имеется множество вариантов агента-передатчика. Например, существует несколько версий TCPагентов, моделирующих различные реализации протокола TCP:

TCP, TCP/ Tahoe, TCP/Reno, TCP/Newreno, TCP/Vegas и др.

использующие разные комбинации алгоритмов TCP (Slow Start,

Congestion Avoidance, Fast Recovery, Fast Retransmit). Кроме того,

имеются агенты для реализации UDP, RTP и RTCP протоколов и многие другие. Подробнее можно прочитать в [3].

Пример создания TCP-агента и подключения его к узлу n0: set tcp [new Agent/TCP]

$ns attach-agent $n0 $tcp

NS2 содержит также несколько вариантов агента-приемника. Функции приемников проще, чем передатчиков, поэтому и агентовприемников в NS2 гораздо меньше. Например, TCP-приемник лишь принимает пакеты и посылает назад уведомления о получении (ACK). Поэтому такой агент в системе один: TCPSink. Кроме него существуют агенты LossMonitor и Null.

Пример создания агента-приемника TCP-сегментов и подключения его к узлу n1:

set sink [new Agent/TCPSink] $ns attach-agent $n1 $sink

Агенты передатчик и приемник необходимо соединить в модели, например:

$ns connect $tcp $sink

С протоколом UDP все обстоит несколько по-другому, потому что уведомления о получении там не предусмотрены. Для передачи используется UDP-агент, а для приема – Null-агент, просто принимающий и уничтожающий все приходящие пакеты.

Пример создания передатчика и приемника UDP-датаграмм: set udp [new Agent/UDP]

$ns attach-agent $n1 $udp

…

set null [new Agent/Null] $ns attach-agent $n3 $null

Пример соединения звеном двух узлов с агентами источником и приемником приведен на рис. 16.14.

Звено Узел2 – Узел1

Рис. 16.14. Пример соединения двух узлов

16.2.7. Абстракции прикладного уровня – приложения

За прикладной уровень в NS2 отвечают приложения (Applications). Приложение прикрепляется к агенту и служит для создания трафика. В NS2 имеются приложения, моделирующие трафик, характерный для реальных протоколов прикладного уровня (FTP и Telnet), а также абстрактные генераторы трафика различного типа (например, CBR – простейший генератор трафика с постоянным темпом выдачи пакетов). Приложения запускаются и останавливаются пользовательскими at-событиями [2, 3].

Пример создания FTP-приложения, подключения его к агенту TCP и at-событий запуска и останова FTP-трафика:

set ftp [new Application/FTP]

$ftp attach-agent $tcp

…

$ns at 1.0 "$ftp start" $ns at 4.0 "$ftp stop"

Параметры трафика. В качестве приложений (не считая приложения FTP или Telnet) в NS2 можно использовать генераторы трафика:

Парето (Pareto);

экспоненциальный (Exponential);

постоянный (CBR) и др.

Пример:

set expo [new Application/Traffic/Exponential]

Общие параметры для объектов выше описанных приложений:

При создании приложения Exponential/Pareto можно задавать дополнительно следующие параметры:

burst_time_ – время периода On (пачки) в секундах;

idle_time_ – время периода Off (ожидания) в секундах.

Приложение Pareto, кроме того обладает свойством:

shape_ – коэффициент формы – параметр распре-

деления.

Для приложения CBR характерно следующее:

interval_ – интервал между передачей пакетов в

секундах;

random_ – флаг, показывающий наличие случайного

шума во время передачи (по умолчанию 0);

maxpkts_ – максимальное число передаваемых пакетов

(по умолчанию 228).

Пример:

$expo set packetSize_ 210 $expo set burst_time_ 500ms $expo set idle_time_ 200ms $expo set rate_ 200k

Если параметры не заданы, NS2 использует значения по умолчанию.

Откроем файл записи трассировки моделирования:

#Открыть файл «out.nam» для записи трассировки set nf [open out.nam w]

Зададим симулятору опцию трассировки для последующей визуализации в NAM и укажем файл для записи:

$ns namtrace-all $nf

Аналогично открываем файл для записи трассировки и задаем опцию трассировки для последующей статистической обработки:

set f [open out.tr w] $ns trace-all $f

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

NAM:

#Определить процедуру "finish" proc finish {} {

global ns nf

#Метод flush-trace выгружает

#результаты трассировки в соответствующие файлы $ns flush-trace

#Закрыть файл трассировки для визуализатора NAM close $nf

#Запустить визуализатор NAM exec nam out.nam &

#Выйти из симуляции exit 0

}

Создадим четыре узла:

#Создать 4 узла set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node]

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

#Создать звенья между узлами

$ns duplex-link $n0 $n2 2Mb 10ms DropTail $ns duplex-link $n1 $n2 2Mb 10ms DropTail $ns duplex-link $n2 $n3 1.7Mb 20ms DropTail

#Установить размер очереди звена n2-n3 равным 10 $ns queue-limit $n2 $n3 10

Зададим служебные параметры для визуализатора NAM: положение связей на отображаемой схеме и отображение состояния линии связи n2-n3:

#Задать расположение соединений узлов для

#отображения

$ns duplex-link-op $n0 $n2 orient right-down $ns duplex-link-op $n1 $n2 orient right-up $ns duplex-link-op $n2 $n3 orient right

#Мониторинг очереди звена n2-n3 для NAM $ns duplex-link-op $n2 $n3 queuePos 0.5

Создадим агент TCP и подключим его к узлу n0:

#Установить TCP соединение set tcp [new Agent/TCP]

$ns attach-agent $n0 $tcp

Создадим агент TCPSink и подключим его к узлу n3: set sink [new Agent/TCPSink]

$ns attach-agent $n3 $sink

Укажем, что агент TCP должен передавать данные агенту TCPSink: $ns connect $tcp $sink

$tcp set fid_ 1 #белый

Создадим агент UDP и подключим его к узлу n1:

#Установить UDP соединение set udp [new Agent/UDP]

$ns attach-agent $n1 $udp

Создадим агент Null и подключим его к узлу n3: set null [new Agent/Null]

$ns attach-agent $n3 $null

Укажем, что агент UDP должен передавать данные агенту Null: $ns connect $udp $null

$udp set fid_ 2 #черный

Создадим генератор трафика FTP и подключим его к агенту TCP:

#Задать передачу ftp-трафика через tcp-соединение set ftp [new Application/FTP]

$ftp attach-agent $tcp

Создадим генератор трафика CBR, подключим его к агенту UDP и зададим параметры:

#Задать передачу cbr-трафика через udp-соединение set cbr [new Application/Traffic/CBR]

$cbr attach-agent $udp $cbr set type_ CBR

$cbr set packet_size_ 1000 $cbr set rate_ 1mb

$cbr set random_ false

Зададим at-события, управляющие ходом моделирования:

пуск и остановка генераторов трафика:

#Записать в планировщик события для CBR и FTP

#агентов

$ns at 0.1 "$cbr start" $ns at 1.0 "$ftp start" $ns at 4.0 "$ftp stop" $ns at 4.5 "$cbr stop"

вызов определенной ранее процедуры "finish" после 5 секунд модельного времени:

#Вызов процедуры finish через 5 секунд симуляции $ns at 5.0 "finish"

Запустим моделирование: $ns run

Результат выполнения приведенного выше tcl-скрипта в виде визуализации network animator приведен на рис. 16.16.

Рис. 16.16. Фрагмент симуляции

16.4.Средства для визуализации, сбора и обработки результатов симуляции

Обработка результатов моделирования является целью самого моделирования. Результаты моделирования заключены в трейсфайлах различного типа. Трейс-файл представляет собой текст в формате ASCII, в котором зарегистрированы необходимые события моделирования [1, 6].

16.4.1. Файлы трассировки

Для того чтобы трейс-файл был создан, в скрипт необходимо добавить следующие строки:

set f [open out.tr w] $ns trace-all $f

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

файлы только с таким расширением (в приведенном примере имя файла трассировки out.tr).

Одна строка файла трассировки содержит следующие поля

(рис. 16.17):

Рис. 16.17. Формат строки трейс-файла

поле «Событие» может содержать: r – принятие пакета узлом;

+– постановка пакета в очередь; - – снятие с очереди;

d – отбрасывание пакета из очереди;

поле «Время» показывает модельное время события в секундах;

поле «От узла» означает последний узел, который обрабатывал данный пакет;

поле «К узлу» показывает, к какому узлу этот пакет направлен;

поле «Тип пакета» указывает на то, к какому приложению или агенту относится данный пакет. Если транспортным агентом является UDP, то указывается приложение, если TCP, то указывается ―tcp‖ – пакет или ―ack‖ – подтверждение;

поле «Размер пакета» содержит размер пакета сетевого уровня с учетом IP заголовка;

поле «Флаги» содержит шесть флагов. Четыре из них используются для явного извещения о перегрузке. Первые два заполняют биты 6 и 7 в поле ToS заголовка IP, а следующие два — в заголовке TCP. Остальные два флага обозначают приоритет и быстрый старт TCP соответственно;

поле «Идентификатор потока» совпадает с полем fid (flow ID)

взаголовке IPv6;

поля «Адрес источника» и «Адрес приемника» имеют формат узел.порт (например, 1.0);

поле «Порядковый номер» показывает номер пакета на транспортном уровне;

поле «Идентификатор пакета» говорит само за себя.

Существуют и другие файлы трассировки. Например, визуализатор NAM использует свой формат файла трассировки. Некоторые виды трейс-файлов предназначены для регистрации событий в беспроводных сетях.