Коды типов состояния каналов

Поле идентификатор канала определяет его характер, в зависимости от этого идентификатором может быть IP-адрес маршрутизатора или сети. Маршрутизатор, рекламирующий канал определяет адрес этого маршрутизатора. Поле порядковый номер канала позволяет маршрутизатору контролировать порядок прихода сообщений и их потерю. Поле возраст канала определяет время в секундах с момента установления связи. После обмена сообщениями с соседями маршрутизатор может выяснить, что часть данных в его базе устарела. Он может послать своим соседям запрос с целью получения свежей маршрутной информации о каком-то конкретном канале связи. Сосед, получивший запрос, высылает необходимую информацию. Запрос посылается в соответствии с форматом, показанном ниже (смотри приложение рис. 2.6):

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

Сообщение об изменении маршрутов

Сообщения об изменениях маршрутов могут быть вызваны следующими причинами:

1. Возраст маршрута достиг предельного значения (lsrefreshtime).

2. Изменилось состояние интерфейса.

3. Произошли изменения в маршрутизаторе сети.

4. Произошло изменение состояния одного из соседних маршрутизаторов.

5. Изменилось состояние одного из внутренних маршрутов (появление нового, исчезновение старого и т.д.)

6. Изменение состояния межзонного маршрута.

7. Появление нового маршрутизатора, подключенного к сети.

8. Вариация виртуального маршрута одним из маршрутизаторов.

9. Возникли изменения одного из внешних маршрутов.

10. Маршрутизатор перестал быть пограничным для данной as (например, перезагрузился).

Каждое сообщение о состоянии канала начинается с заголовка - "объявление состояния канала" (LS- link state). Формат этого типа заголовка приведен ниже (20 октетов):

Поле возраст ls информации (смотри приложение рис. 2.8) определяет время в секундах с момента объявления состояния канала. Поле опции содержит значения типов сервиса (TOS), поддерживаемые маршрутизатором, рассылающим маршрутную информацию. Поле тип LS (тип состояния канала) может принимать значения, описанные выше в табл. 2.3. Следует обратить внимание, что код, содержащийся в этом поле, определяет формат сообщения. Поле длина задает размер сообщения в октетах, включая заголовок. В результате получается сообщение с форматом, показанным на смотри приложение рис. 2.9. Зарезервированный октет должен быть обнулен. Идентификатор связи определяет тип маршрутизатора, подключенного к каналу. Действительное значение этого поля зависит от поля тип. В свою очередь информация о канале также зависит от поля тип. Число tos определяет многообразие метрик, соответствующих видам сервиса, для данного канала. Последовательность описания метрик задается величиной кода TOS. Таблица кодов TOS, принятых в OSPF протоколе приведена ниже.

Коды типа сервиса

Если бит V=1 (virtual), маршрутизатор является оконечной точкой активного виртуального канала. Если бит E (external) равен 1, маршрутизатор является пограничным для автономной системы. Бит B=1 (border) указывает на то, что маршрутизатор является пограничным для данной области. Поле тип может принимать значения, приведенные в таблице 2.5.

Коды типов связей

Таблица 2.4. Коды типа сервиса (TOS)

OSPF-код	TOS-коды	TOS(RFC-1349)
0	0000	Обычный сервис
2	0001	Минимизация денежной стоимости
4	0010	Максимальная надежность
8	0100	Максимальная пропускная способность
16	1000	Минимальная задержка

Таблица 2.5. Коды типов связей (см. смотри приложение рис. 2.9)

Код типа связи	Описание
1	Связь с другим маршрутизатором по схеме точка-точка
2	Связь с транзитной сетью
3	Cвязь с оконечной сетью
4	Виртуальная связь (например, опорная сеть или туннель)

Поле идентификатор канала характеризует объект, с которым связывается маршрутизатор. Примеры идентификаторов представлены в таблице:

Коды идентификаторов канала



Таблица 2.6. Коды идентификаторов канала

Код идентификатора	Описание
1	Идентификатор соседнего маршрутизатора
2	IP-адрес основного маршрутизатора (по умолчанию)
3	IP-адрес сети/субсети
4	Идентификатор соседнего маршрутизатора

Маршрутизатор, получивший OSPF-пакет, посылает подтверждение его приема. Этот вид пакетов имеет тип=5 и структуру, отображенную на смотри приложение рис. 2.10. Получение нескольких объявлений о состоянии линий может быть подтверждено одним пакетом. Адресом места назначения этого пакета может быть индивидуальный маршрутизатор, группа маршрутизаторов или все маршрутизаторы автономной системы.

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

Следует помнить, что приведенные ниже сообщения должны быть снабжены стандартными 24-октетными OSPF-заголовками (на смотри приложение рис. 2.11 отсутствует).

Сетевая маска относится к описываемой сети, а поле подключенный маршрутизатор содержит идентификатор маршрутизатора, работающего в сети. Информация об адресатах в пределах автономной системы передается LS-сообщениями типа 3 и 4. Тип 3 работает для IP-сетей. В этом случае в качестве идентификатора состояния канала используется IP-адрес сети. Если же адресатом является пограничный маршрутизатор данной AS, то используется LS-сообщение типа 4, а в поле идентификатор состояния канала записывается OSPF-идентификатор этого маршрутизатора. Во всех остальных отношениях сообщения 3 и 4 имеют идентичные форматы (смотри приложение рис. 2.12):

Поля, следующие после заголовка, повторяются в соответствии с числом описываемых объектов. Рекламирование внешних маршрутов относится к пятому типу. Эта информация рассылается пограничными маршрутизаторами. Информация о каждом внешнем адресате, известном маршрутизатору, посылается независимо. Этот вид описания используется и для маршрутов по умолчанию, для которых идентификатор состояния канала устанавливается равным 0.0.0.0 (аналогичное значение принимает при этом и сетевая маска). Формат такого сообщения представлен на смотри приложение рис. 2.13.

1.6 Формат описания внешних маршрутов

Сетевая маска характеризует место назначения рекламируемого маршрута. Так для сети класса A маска может иметь вид 0xFF000000. Последующий набор полей повторяется для каждого вида TOS. Поля для TOS=0 заполняются всегда, и это описание является первым. Бит E характеризует внешнюю метрику. Если E=0, то она может непосредственно (без преобразования) сравниваться с метриками других каналов. При E=1 метрика считается больше любой метрики. Поле адрес пересылки указывает на место, куда будут пересылаться данные, адресованные рекламируемым маршрутом. Если адрес пересылки равен 0.0.0.0, данные посылаются пограничному маршрутизатору автономной системы - источнику данного сообщения. Метка внешнего маршрута - 32-битовое число, присваиваемое каждому внешнему маршруту. Эта метка самим протоколом OSPF не используется и предназначена для информирования других автономных систем при работе внешних протоколов маршрутизации. Маршрутная таблица OSPF содержит в себе:

· IP-адрес места назначения и маску;

· тип места назначения (сеть, граничный маршрутизатор и т.д.);

· тип функции (возможен набор маршрутизаторов для каждой из функций TOS);

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

· тип пути (характеризует путь как внутренний, межобластной или внешний, ведущий к AS);

· цена маршрута до цели;

· очередной маршрутизатор, куда следует послать дейтограмму;

· объявляющий маршрутизатор (используется для межобластных обменов и для связей автономных систем друг с другом).

Преимущества и недостатки OSPF

Преимущества OSPF:

1. Для каждого адреса может быть несколько маршрутных таблиц, по одной на каждый вид IP-операции (TOS).

2. Каждому интерфейсу присваивается безразмерная цена, учитывающая пропускную способность, время транспортировки сообщения. Для каждой IP-операции может быть присвоена своя цена (коэффициент качества).

3. При существовании эквивалентных маршрутов OSFP распределяет поток равномерно по этим маршрутам.

4. Поддерживается адресация субсетей (разные маски для разных маршрутов).

5. При связи точка-точка не требуется IP-адрес для каждого из концов. (Экономия адресов!)

6. Применение мультикастинга вместо широковещательных сообщений снижает загрузку не вовлеченных сегментов.

Недостатки:

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

2. OSPF является лишь внутренним протоколом.

Число маршрутных таблиц может быть равно числу значений качества обслуживания.

1.7 Внешний протокол BGP

Протокол BGP (RFC-1267 BGP-3; RFC-1665; RFC-1467 BGP-4; -1771, -1863, -1997, -2439, -2545, -2796, -2858, -2918, -3065, -3107, -3392) разработан компаниями IBM и CISCO. Главная цель BGP - сократить транзитный трафик. Местный трафик либо начинается, либо завершается в автономной системе (AS); в противном случае - это транзитный трафик. Системы без транзитного трафика не нуждаются в BGP (им достаточно EGP для общения с транзитными узлами). Но не всякая ЭВМ, использующая протокол BGP, является маршрутизатором, даже если она обменивается маршрутной информацией с пограничным маршрутизатором соседней автономной системы. AS передает информацию только о маршрутах, которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов (UPDATE-сообщения, рис. 4.1). Максимальная длина таких сообщений составляет 4096 октетов, а минимальная 19 октетов. Каждое сообщение имеет заголовок фиксированного размера. Объем информационных полей зависит от типа сообщения.

Общая схема работы BGP такова. BGP-маршрутизаторы соседних АС, решившие обмениваться маршрутной информацией, устанавливают между собой соединения по протоколу BGP и становятся BGP-соседями (BGP-peers).

Далее BGP использует подход под названием path vector, являющийся развитием дистанционно-векторного подхода. BGP-соседи рассылают (анонсируют, advertise) друг другу векторы путей (path vectors). Вектор путей, в отличие от вектора расстояний, содержит не просто адрес сети и расстояние до нее, а адрес сети и список атрибутов (path attributes), описывающих различные характеристики маршрута от маршрутизатора-отправителя в указанную сеть. В дальнейшем для краткости мы будем называть набор данных, состоящих из адреса сети и атрибутов пути до этой сети, маршрутом в данную сеть.

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

Реализация BGP

Пара BGP-соседей устанавливает между собой соединение по протоколу TCP, порт 179. Соседи, принадлежащие разным АС, должны быть доступны друг другу непосредственно; для соседей из одной АС такого ограничения нет, поскольку протокол внутренней маршрутизации обеспечит наличие всех необходимых маршрутов между узлами одной автономной системы.

Поток информации, которым обмениваются BGP-соседи по протоколу TCP, состоит из последовательности BGP-сообщений. Максимальная длина сообщения 4096 октетов, минимальная - 19

1.8 Перспективные разработки в области создания алгоритмов маршрутизации устойчивых к дестабилизации

Netsukuku

Протокол Npv7

Протокол NETSUKUKU, первая версия.

NETSUKUKU использует свой собственный протокол Npv7, который родился из трёх предыдущих версий. Первый был очень похож на нынешние протоколы динамического управления: сеть была фактически разделена на несколько групп, и каждый сигнальный узел имел чёткую карту полной сети. Такая система не могла работать с NETSUKUKU, так как требовалось постоянно обновлять карту сети и каждое обновление приводило к перегрузке сети. Кроме того, после каждого обновления сети требовалось пересчитать все пути.

Разграничения NETSUKUKU.

Базовые определения:

src_node

Исходный узел. Узел, который отправляет пакет узлу назначения dst_node.

dst_node

Узел назначения. Узел, который получает пакет от исходного узла src_node.

r_node

Удалённый узел, от узла X, это любой узел связанный с узлом X.

g_node

Группа узлов или группа групп узлов.

b_node

Пограничный узел -- узел, соединённый с двумя (r_node) узлами из разных (g_node) групп узлов.

h_node

Цепляющийся узел -- узел, подсоединяющийся к NETSUKUKU.

int_map

Внутренняя карта. Внутренняя карта узла X содержит информацию о группе узлов (g_node), к которой он принадлежит.

ext_map

Внешняя карта. Карта содержит информацию о группах узлов.

bmap/bnode_map

Карта пограничных узлов. Карта содержит информацию о (b_node) пограничных узлах.

Npv7 II Лазерная передача, направленная сразу нескольким неспецифицированным приёмникам.

Npv7 II вторая версия прокола Npv7.

NETSUKUKU разделена на много маленьких групп узлов, до ста узлов в каждой группе, и каждый узел имеет внешнюю карту маршрутов. Все группы организованны в мультигруппы, называемые quadro group_node. Для того, чтобы создать новый маршрут и соединиться с заданным узлом, исходный узел, используя свою внешнюю карту, сначала ищет наилучший путь до пограничного узла группы, к которой принадлежит узел назначения.

QSPN

Тому, кто знаком с физикой волны, будет просто понять, как работает qspn. Если бросить камень в бассейн с водой, то можно наблюдать следующее: волны начинают распространяться из начальной точки, причём каждая волна рождает новую волну, которая продолжает распространяться и рождать все новые и новые волны. Когда волна ударяется о края бассейна или о какую-то преграду, она отражается и начинает распространяться в обратную сторону. В применении к qspn камень -- это qspn_starter, бассейн -- gnode, а каждая волна -- tracer_pkt. Каждая новая волна несёт с собой информацию о родившей её волне. Когда tracer_pkt (волна) достигает extreme_node (препятствия или границы бассейна), рождается qspn_open (отражённая волна).

QSPN базируется на описанном принципе. Начиная трассировку узлов, каждый узел посылает qspn_pkt, называемый qspn_close, становясь тем самым qspn_starter. Qspn_pkt это обычный tracer_pkt, но его метод вещания немного отличается от остальных. Каждый пакет, который получает qspn_close, «закрывает» линк узла, от которого получил этот пакет и отсылает пакеты по всем своим остальным линкам. Все последующие полученные qspn_close пакеты будут переправляется по всем оставшимся незакрытым линкам. Через некоторый промежуток времени появляются узлы, у которых все линки будут закрыты. Такие узлы становятся extreme_node и посылают в качестве ответа другой qspn_pkt пакет (qspn_open). Другими словами, qspn_open пакет отправляется, после того как получены qspn_close пакеты от всех узлов. Пакет qspn_open содержит всю информацию, собранную в последнем полученном пакете qspn_close. Extreme_node посылает пакет qspn_open по всем своим линкам, кроме того узла, от которого он получил последний qspn_close; этому узлу отсылается пустой пакет. Другими словами, пакет qspn_open отправляется после того, как узел получил пакет qspn_close от всех узлов. Узел, получивший пакет qspn_open, открывает все линки. Узлы со всеми открытыми связями абсолютно ничего не делают. Таким образом, гарантируется законченность обмена пакетами qspn_close. У qspn_open пакетов также есть идентификационный номер(sub_id) -- число, которое идентифицирует во внешних картах узлы «extreme_node», сгенерировавшие эти qspn_open пакеты. Sub_id, сгенерированный в самом первом пакете и не меняющийся во всех порождённых(qspn_open) пакетах, используется для управления большим числом qspn_pkt пакетов, так как рано или поздно каждый узел сгенерирует пакет qspn_open, и все они должны быть независимы и отличны друг от друга. Действительно, все узлы, которые имеют только одну связь, -- это узлы extreme_node, ведь когда они получают qspn_close, они уже закрыты. После отправки пакета qspn_open узел не может отвечать больше никому и ни на какие полученные qspn_pkt пакеты, поэтому он больше ничего не отправляет.

Узел qspn_starter, который запустил qspn, становится обычным узлом, но не отправляет пакет qspn_open, так как отправил первый qspn_close. Кроме того, чтобы обновить свою собственную карту, узел будет использовать все полученные qspn_close пакеты, кроме тех, которые были отправлены такими же qspn_start узлами. Таким образом, поддерживается стабильность в случае наличия более одного узла «qspn_starter».

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

Вместо DNS в сети Netsukuku используется «анархическая» доменная система ANDNA (Abnormal Netsukuku Domain Name Anarchy). В ней каждый узел представляет собой самостоятельный маршрутизатор трафика, работающий под GNU/Linux. Протокол чрезвычайно экономно потребляет ресурсы, так что на каждом узле для поддержки коммуникации требуется максимум 355 КБ оперативной памяти и минимальная вычислительная мощность. В принципе, этим требованиям удовлетворяют даже современные мобильные телефоны, так что аналогичную распределенную сеть можно создать в том числе на их основе. Тогда мобильники будут работать в обход централизованных базовых станций.

Понятно, что карта маршрутизации для такой сети, в которую потенциально могут входить миллиарды узлов, может вырасти до совершенно невообразимых размеров. Однако разработчикам удалось решить эту проблему. Новый мета-алгоритм Quantum Shortest Path Netsukuku (QSPN) с использованием фракталов позволяет уместить карту почти всей сети в файл размером менее 2 КБ. Разработан также специальный протокол Npv7_HT для динамической маршрутизации внутри сети с неограниченным количеством узлов.

Сеть Netsukuku полностью анонимна и обеспечивает абсолютную свободу коммуникаций. Это не виртуальная «надстройка» над интернетом, а реальная физическая сеть, которая будет существовать параллельно. Узлы в «альтернативном интернете» должны осуществлять физическое соединение друг с другом в обход «официальных» каналов (например, по WiFi).

Вывод по главе

Исходя из вышерассмотренного материала видно, что в области создания алгоритмов маршрутизации для ИВС инвариантной к дестабилизации ведутся активные разработки новой сети и нового алгоритма Npv7_HT, который имеет более качественные характеристики, чем его предшественники. Перспективная разработка алгоритма будет поддерживать не только локальные проводные, но и беспроводные локальные сети. Существующие алгоритмы маршрутизации из всего вышеперечисленного удовлетворяют современные требования предъявляемые к ИВС инвариантной к дестабилизации, поэтому необходимо свести данные в таблицу для выявления наиболее удовлетворяющего требованиям для данной ИВС алгоритма маршрутизации.

1.9 Выбор алгоритма маршрутизации

	Max длинна сообщений	Скорость передачи данных	Метрики	Подержка субсетей	Инициализация	Пропускная способность	Инкапсуляция пакетов	Связь	Переходные процессы
RIP	средняя	Средняя	Число шагов до цели	нет	Широковещательные запросы	Средняя	да	Точка-точка	медленно
OSPF	большая	Высокая	Коэффициент качества обслуживания	да	Сообщения типа Hello, мультикастинговые сообщения	Высокая	нет	Точка-точка	быстро
BGP	малая	Средняя	Число шагов до цели	нет	Связь на транспортном протокольном уровне	Средняя	да	Клиент-точка	медленно
Npv7	большая	Высокая		да		высокая	нет	Ячеистая сеть, р2р	быстро

Сравнение протоколов RIP и OSPF по затратам на широковещательный трафик

В сетях, где используется протокол RIP, накладные расходы на обмен маршрутной информацией строго фиксированы. Если в сети имеется определенное число маршрутизаторов, то трафик, создаваемый передаваемой маршрутной информацией, описываются формулой (1):

(1) F = (число объявляемых маршрутов/25) x 528 (байтов в сообщении) x (число копий в единицу времени) x 8 (битов в байте)

В сети с протоколом OSPF загрузка при неизменном состоянии линий связи создается сообщениями HELLO и обновленными объявлениями о состоянии связей, что описывается формулой (2):

(2) F = { [ 20 + 24 + 20 + (4 x число соседей)] x (число копий HELLO в единицу времени) }x 8 + [(число объявлений x средний размер объявления) x (число копий объявлений в единицу времени)] x 8,

где 20 - размер заголовка IP-пакета,

24 - заголовок пакета OSPF,

20 - размер заголовка сообщения HELLO,

4 - данные на каждого соседа.

Интенсивность посылки сообщений HELLO - каждые 10 секунд, объявлений о состоянии связей - каждые полчаса. По связям "точка-точка" или по широковещательным локальным сетям в единицу времени посылается только одна копия сообщения, по NBMA сетям типа frame relay каждому соседу посылается своя копия сообщения. В сети frame relay с 10 соседними маршрутизаторами и 100 маршрутами в сети (подразумевается, что каждый маршрут представляет собой отдельное OSPF-обобщение о сетевых связях и что RIP распространяет информацию о всех этих маршрутах) трафик маршрутной информации определяется соотношениями (3) и (4):

(3) RIP: (100 маршрутов / 25 маршрутов в объявлении) x 528 x (10 копий / 30 сек) = 5 632 б/с

(4) OSPF: {[20 + 24 + 20 + (4 x 10) x (10 копий / 10 сек)] + [100 маршрутов x (32 + 24 + 20) + (10 копий / 30 x 60 сек]} x 8 = 1 170 б/с

Как видно из полученных результатов, для нашего гипотетического примера трафик, создаваемый протоколом RIP, почти в пять раз интенсивней трафика, создаваемого протоколом OSPF.

Вывод

Проведя сравнительный анализ алгоритмов маршрутизации я выявил, что наиболее полно требования дипломного проекта отвечает алгоритм OSPF, который я и предполагаю использовать для дальнейших исследований ИВС инвариантной к ИТВ противника.

1.10 СРАВНИТЕЛЬНЫЙ АНАЛИЗ СКОРОСТИ ПЕРЕДАЧИ ДАННЫх ЧЕРЕЗ ПРОГРАММНЫЕ МАРШРУТИЗАТОРЫ НА БАЗЕ ОС MS WINDOWS И SUSE LINUX

В настоящее время информационно-вычислительные сети достигли такого уровня развития, сложности и масштабов, что уже практически невозможно представить их без специализированных программно-аппаратных средств, обеспечивающих передачу данных как между двумя узлами, так и групповое вещание и широковещание. Кроме того сети современных корпораций, особенно средних и крупных, представляют собой достаточно сложный граф, который отнюдь не всегда является строго деревом, где имеется одна точка общая подключения к Интернет, а вся сеть в виде дерева “разрастается” вниз от нее, и конечные листья этого деревья относятся к конкретным подразделениям корпорации. Часто в сети имеются избыточные линии связи, которые в первую очередь служат для повышения целостности и надежности функционирования сети. В такой ситуации при передаче данных между узлами сети может иметься не один, а несколько маршрутов, и эффективная маршрутизация оказывается одной из наиболее важных задач.

На сегодняшний день для сетей с коммутацией пакетов существуют множество как протоколов маршрутизации, так и программно-аппаратных систем выполняющих функцию маршрутизации. Однако, нередко специализированные аппаратные маршрутизаторы [1], несмотря на все их достоинства по техническим показателям, оказываются довольно дорогостоящими, и поэтому зачастую также используются и программные маршрутизаторы, представляющие собой компьютеры класса IBM PC на базе процессоров Intel x86 [2] с установленной сетевой операционной системой и программным пакетом маршрутизации.

В рамках профессиональной деятельности у автора была возможность сравнить программные маршрутизаторы, построенные на базе компьютера IBM PC при двух различных операционных системах MS Windows Server [3] и SUSE Linux [4] со встроенными программными модулями маршрутизации. Автором было проведено небольшое экспериментальное исследование, цель которого состояло в том, чтобы выявить максимально возможную скорость передачи данных через маршрутизатор при заданной аппаратной и программной конфигурации. Кроме того, также интерес представляла зависимость загрузки процессора маршрутизатор от скорости передачи данных между двумя сетями, подключенных к нему.

? Аппаратная конфигурация маршрутизатора:

- Процессор: Intel Celeron 2400 MHz

- Материнская плата: Intel D865GLC

- Оперативная память: 512 Мбайт DDR PC2700

- Жесткий диск: 34.5 Гбайт Western Digital SATA

- Два сетевых адаптера: REALTEK Gigabit Ethernet (RTL8169).

? Операционная система и пакет маршрутизации: в одном случае использовалась ОС MS Windows 2003 Enterprise Server со встроенной службой Routing and Remote Access Services. Во втором случае использовалась ОС SUSE 9.2 Linux со встроенным пакетом IP Route 2.

? Сетевая конфигурация: использовался стек протоколов TCP/IP [5], причем к одному сетевому адаптеру были привязаны две различные IP-сети, назовем их Real 14 и Private 14, а к другому сетевому адаптеру были привязаны, две другие IP-сети - Real 17 и Private 17. Таким образом, к двум сетевым адаптерам маршрутизатора были привязаны четыре различных маршрутизируемых IP-сетей.

Для измерения скорости передачи данных использовались различные соединения типа точка - точка, и передача данных и измерение скорости осуществлялась при помощи специализированной программы NETCPS. Соединение осуществлялось между компьютерами со 100 Mbit сетевыми адаптерами, находящимися в разных маршрутизируемых IP-сетях (более того соединения выбирались таким образом, чтобы задействовать оба сетевых адаптера маршрутизатора). Для выяснения максимально возможной суммарной скорости передачи данных через маршрутизатор использовались несколько одновременных передач между несколькими парами узлов сети. Для оценки загрузки процессора во время передачи данных использовались встроенные в ОС средства - утилита Task Manager в MS Windows и команда Top в SUSE Linux.

Результаты измерений сведены в таблицах 1 - 4. В таблице 1 представлены результаты измерений при одном соединении точка - точка, таблице 2 - при двух одновременных соединениях, таблице 3 - при 4-х соединениях, таблице 4 - при 6-ти соединениях.

Таблица 1. Скорость передачи данных / Загрузка процессора при последовательном тестировании одиночных соединений.

	Hardware:	P4 Celeron 2.4 GHz, 512MB	P4 Celeron 2.4 GHz, 512MB
	Software:	MS Windows 2003 EE + SP1	SuSE 9.2 LinuX
Network Link:	Avg. Transfer Rate, MB /s	Avg. CPU Load, %	Avg. Transfer Rate, MB /s	Avg. CPU Load, %
Real14 - Real17	6.46	30	6.38	20
Private14 - Private17	10.22	44	10.45	32
Real14 - Private14	6.92	32	6.85	19
Real17 - Private17	8.01	36	8.48	26
Real14 - Private17	6.21	27	7.14	19
Real17 - Private14	9.41	42	9.24	30

Таблица 2. Скорость передачи данных / Загрузка процессора при параллельном тестировании 2-x соединений.

Network Link:	Avg. Transfer Rate, MB /s	Avg. CPU Load, %	Avg. Transfer Rate, MB /s	Avg. CPU Load, %
Real14 - Private17	6.31	68	6.63	47
Real17 - Private14	9.13		8.81
Total:	15.44	68	15.44	47

Таблица 3. Скорость передачи данных / Загрузка процессора при параллельном тестировании 4-x соединений.

Network Link:	Avg. Transfer Rate, MB /s	Avg. CPU Load, %	Avg. Transfer Rate, MB /s	Avg. CPU Load, %
Real14 - Private17	4.99	96	5.94	75
Private14 - Real17	4.41		5.08
Real17 - Private14	6.05		7.89
Private17 - Real14	4.51		5.47
Total:	19.96	96	24.38	75



Таблица 4. Скорость передачи данных / Загрузка процессора при параллельном тестировании 6-ти соединениях

Network Link:	Avg. Transfer Rate, MB /s	Avg. CPU Load, %	Avg. Transfer Rate, MB /s	Avg. CPU Load, %
Real14 - Private17	-	-	5.02	99
Private14 - Real17	-		4.49
Real17 - Private14	-		5.76
Private17 - Private14	-		6.26
Private14 - Private17	-		4.31
Private17 - Real14	-		5.56
Total:	-	-	31.40	99

Из таблиц 1 - 4 видно, что при равной аппаратной конфигурации, программной маршрутизатор на базе ОС MS Windows раньше, чем SUSE Linux “входит в насыщение”. На заданной аппаратной конфигурации уже при достижении суммарной скорости, передаваемой через маршрутизатор, около 20 Мбайт/с служба маршрутизации ОС MS Windows “загружает” процессор практически полностью, пакет маршрутизации ОС SUSE Linux имеет “больший запас”: обеспечивает скорость передачи до 32 Мбайт/с при 100%-й загрузке процессора маршрутизатора.

С одной стороны здесь следует отметить, что в таких случаях - программной обработки чего-либо, характер загрузки процессора зависит от особенностей и качества реализации драйвера устройства - в нашем случае это сетевой адаптер. С другой стороны драйвер совместно с самим сетевым адаптером захватывает функции только 1-го и 2-го уровня модели OSI, а за маршрутизацию, относящуюся к 3-му уровню, отвечают специальные драйверы и службы маршрутизации, которые встроены в ОС в нашем случае. Поэтому в данном случае, различия по результатам при прочих равных условиях, обусловлены именно различием двух разных операционных систем со встроенными средствами маршрутизации.

Наконец, последнее, что следует отметить - это то, что по результатам нетрудно заметить линейный характер зависимости между загрузкой процессора и суммарной скоростью передаваемых через маршрутизатор данных. В грубом приближении, обозначая суммарную скорость через V, а загрузку процессора - через L, можем сказать, что:

L=K*V

0?L?100 (1)

где, K - некоторый коэффициент пропорциональности, зависящий от множества факторов: характеристик аппаратных средств компьютера, особенностей организации ОС, служб маршрутизации и др. В нашем случае, для заданной аппаратной конфигурации, для ОС MS Windows Server коэффициент K ~ 4.5, а для ОС SUSE Linux - K ~ 3.2

вывод: Исходя из расчетов приведенных выше видно, что целесообразнее применять ОС MS Windows Server для повышения коэффициента пропорциональности, но при этом загрузка процессора намного меньше у ОС SUSE Linux, что увеличивает производительность системы в целом, поэтому целесообразнее при проектировании ИВС, инвариантной ИТВ противника использовать ОС SUSE Linux. Также не маловажным является то, что ОС SUSE Linux использует открытые коды, что способствует использование более широких функциональных возможностей.



Раздел 2

2.1 Моделирование ИВС инвариантной к дестабилизации

маршрутизация сеть переадресация

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

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

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

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

Специализированные языки моделирования делят на три группы, соответствующие видам имитации: для непрерывных, дискретных и комбинированных процессов. Для моделирования дискретных систем широкое распространение получил пакет GPSS (General Purpose Simulation System - общецелевая система моделирования). Написанные с помощью языка GPSS модели получаются более адекватными исследуемой системе, чем построенные с использованием известной теории массового обслуживания. В моделях, написанных на языке GPSS, можно учесть большое количество факторов и отказаться от многих ограничений и допущений.

Основной модуль пакета представляет собой интегрированную среду, включающую помимо транслятора со входного языка средства ввода и редактирования текста модели, ее отладки и наблюдения за процессом моделирования, графические средства отображения атрибутов модели, а также средства накопления результатов моделирования в базе данных и их статистической обработки. Кроме основного модуля в состав пакета входит модуль создания стандартного отчета GPSS/PC, а также ряд дополнительных модулей и файлов.

Ещё одним языком имитационного моделирования дискретных систем является Simpas, который, по мнению разработчиков, по своим возможностям полностью перекрывает специализированный язык GPSS, обладая более высоким быстродействием и гибкостью. Система Simpas оформлена как модуль и потому является открытой по сравнению с GPSS/PC. Это даёт возможность исследователю разрабатывать свои процедуры и включать их в Simpas или подстраивать что-то из уже имеющегося в нём под свои нужды. При разработке моделей на GPSS/PC исследователь ограничен его возможностями, в то время как Simpas позволяет использовать возможности Object Pascal.

Однако следует заметить, что GPSS/PC и Simpas предназначены для работы в операционной системе MS-DOS. Поэтому имеются ограничения, которые в ряде случаев не позволяют осуществить разработку и эксплуатацию моделей сложных систем с требуемой степенью детализации.

Отмеченных недостатков практически не имеет новая общецелевая система моделирования GPSS World, разработанная компанией Minuteman (США). Эта система является развитием GPSS/PC, но приобрела комбинированный характер, т.е. может моделировать как дискретные, так и непрерывные процессы. Эти возможности обеспечиваются как новыми объектами языка GPSS, так и включёнными в состав GPSS World языка Plus - языка программирования низкого уровня. Этот язык сделал GPSS World более открытой системой и позволяет взаимодействовать с другими приложениями, а также создавать пользователями свои библиотеки процедур. Язык Plus вместе с другими инструментальными средствами GPSS World позволил автоматизировать весь цикл исследований от разработки моделей до выработки рекомендаций за счёт новых функций планирования экспериментов и обработки статистики. Наконец, GPSS World работает в операционной системе Windows и максимально ориентирована на использование современных технологий, обеспечивающих высокую интерактивность и визуальное представление информации.

Целью моделирования данной ИВС является:

- оценить скорость распространения информации по структуре;

- Оценить эффективность и преимущества выбранной структуры ИВС;



3.2 Формализация задачи

Постановка задачи.

Вычислительная система состоит из десяти ЭВМ. С интервалом 2 ± 1 мин в систему поступают пакеты, которые адресуются одной из десяти ЭВМ. После обработки задания на первой ЭВМ, время обработки равно 2±1, оно поступает в блок копирования и копия отсылается к последующим ЭВМ и далее по структуре.

Продолжительность обработки заданий на разных ЭВМ характеризуется интервалами времени Т. Смоделировать процесс обработки 1 задания и процесс обработки пакетов за период времени 250 едениц.

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

3.3 Блок схема работы вычислительной системы

Наша вычислительная сеть имеетдесяти канальную систему (каждый канал соответствует одной ЭВМ).

Блок-схема для неё имеет вид - см. приложение - блок схема модели ИВС.

На вход системы подаются транзакты, которые распределяются в каналs обработки- route, ключи (клапаны) этих каналов РС- устройства (ЭВМ), работающие в канале. Попадая в канал, заявка обрабатывается на соответствующем ЭВМ. После обработки на ЭВМ, транзакт считается выполненным и удаляется из системы, а ЭВМ переходит в закрытое состояние. После обработки на ЭВМ транзакт попадает в последующие каналы обработки, где проходит вторичную обработку, после которой он (транзакт) также считается выполненной.



3.4 Листинг программы на языке GPSS

Распределение транзактов на обслуживание среди машин вычислительной системы удобно реализовать через блок TRANSFER (режим статистической передачи). Текст программы приведён в приложении Листинг программы на языке GPSS.

3.5 Описание используемых программных блоков

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

· GENERATE - основной блок для ввода транзактов в модель. Данный блок имеет 2 параметра: первый определяет среднее время между генерацией смежных транзактов; второй параметр - модификатор, изменяющий значение интервала генерации транзактов по сравнению с интервалом, указанным первым параметром. Есть 2 типа модификаторов: модификатор-интервал и модификатор-функция. В нашей программе используется модификатор-интервал, т.к. время генерации транзактов равномерно распределено в заданном интервале.

· TERMINATE - предназначен для вывода транзактов из модели. Единственный (необязательный) параметр данного блока указывает, сколько единиц необходимо вычесть из счётчика завершения при входе каждого транзакта. В нашей программе единственный блок TERMINATE при входе транзакта уменьшает счётчик завершения на единицу.

· START - указывает, что все данные введены и необходимо начинать прогон модели. Параметром этого блока является величина счётчика завершения. Моделирование заканчивается, когда эта величина меньше, либо равна нулю. В нашей задаче моделируется процесс обработки 200 заданий, поэтому счётчик завершения равен 200.

· QUEUE - используется для регистрации входа транзакта в очередь (сбор статистических данных). Первый операнд задаёт номер или имя очереди, второй - определяет число единиц, на которое увеличивается длина очереди (по умолчанию - 1).

· DEPART - «выход из очереди». Уменьшает длину соответствующей очереди, указанной первым операндом на количество единиц, указанное во втором операнде (по умолчанию - тоже 1)/

· TRANSFER - предназначен для передачи входящего в него транзакта в любой другой блок модели. Может работать в следующих режимах: безусловная передача, статистическая передача, режим BOTH, режим ALL, режим PICK, функциональный режим, параметрический режим, подпрограммный режим, одновременный режим. В нашей программе данный блок работает в режиме статистической передачи. В этом режиме первый операнд указывает, какая доля входящих транзактов направляется в блок, указанный третьим операндом. Остальные транзакты направляются в блок, соответствующий второму операнду (или к следующему блоку, если второй операнд опущен).

· SEIZE - моделирование занятия устройства транзактом. Используемый в данном блоке операнд соответствует имени занимаемого устройства.

· RELEASE - освобождение устройства от транзакта, его занимающего. Единственный операнд аналогичен операнду предыдущего (SEIZE) блока.

· ADVANCE - имитация работы устройства, т.е задержка транзакта в течение некоторого интервала модельного времени. Первый операнд содержит значение среднего времени обслуживания; второй операнд - модификатор (аналогично блоку GENERATE).

3.6 Результаты моделирования

Исходный отчёт системы GPSS World.

Приведены в приложении - Результаты моделирования.

Исходный отчёт системы GPSS World.

Анализ результатов моделирования.

Характеристика	Значение
Время распространения транзакта	29.616
Количество обработанных транзактов	34

Из результатов моделирования видно, что Время распространения пакета по сети будет равно 29,616 единиц времени для сети из 10 машин что явлется высоким показателем скорости распространения данных.

3.7 Расчет надежности ПО

Программное обеспечение представлено основной программой; ее параметры надежности следует оценивать по исходному коду полагая, что для приемлемой отладки основной программы предлагается выделить 3000 Программирование надежности программного обеспечения

методом Холстеда:

Словарь: ;

Длина программы: ;

Объем программы: ;

Оценка длины программы: ;

Потанцеальный объем: ;

Уровень программы: ;

Уровень языка: ;

Общее число элементарных мысленных различений:

;

Число потенциальных ошибок: ;

Расчеты:

Интенсивность отказов: ;

Вероятность безотказной работы рассчитываем:

;

Общая формула для нахождения вероятности безотказной работы основной :

;

Вероятность безотказной работы основной программы:

;

По данным расчета:

0,992278;

Среднее время работы на отказ

Общая формула:

;

Вычисление:

Вывод:

По данному заданию я определил надежные характеристики программного комплекса: вероятность безотказного функционирования и среднее время работы до отказа.

вероятность безотказного функционирования составила:

;

среднее время работы до отказа равно:

;

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



Заключение

В данной работе рассмотрен алгоритм маршрутизации OSPF, применяемый в ИВС инвариантной ИТВ противника, смоделирована сеть инвариантная к дестабилизации с оценкой эффективности функционирования ИВС НКУ. Проведен выбор метода и средства исследования и применение его на практике к исследованию программного обеспечения программного маршрутизатора. В результате разработана модель ИВС инвариантной к дестабилизации и произведено моделирование системы с помощью программного средства GPSS, определенно время распространения пакета по сети равном 29.616 едениц времени, а также количество пакетов обработанных за 250 едениц времени с интервалом времени 2±1 едениц времени, оно равно 34 пакета, что является высокими показателями прохождения пакетов в сети, также определено вероятность безотказного функционирования составила:

;

среднее время работы до отказа равно:

;

Из данных расчетов, можно сделать вывод о высокой надежности ПО.

Таким образом, считаю, что цели и задачи дипломного проекта достигнуты.

Размещено на Allbest.ru