CC BY
39
Секция 1 Секция 2 Секция 3 Секция 4 Секция 5 Секция 6 Секция 7 Секция 8
8 МЗР-9 8 МЗР 9 8 МЗР-9 8 МЗР -9 8 МЗР-9 8 МЗР-9 8 МЗР-9 8 МЗР -9
д=84
q=95
<7=99 q=95 9=87 9=79
Рис. 5. Топология локального корректора
9=61
9=57
ции. Процедура оптимизации использует случайный поиск. В ходе оптимизации удалось также уменьшить число звеньев N = 8. Параметры локальных звеньев после оптимизации приведены в табл. 2, а характеристики затухания и погрешность корректирования - на рис. 4.
Погрешность корректирования секции, как следует из рис. 4, не превышает 0,0035 дБ, а для всего корректора из 8 секций погрешность 0,028. При этом число локальных звеньев в секции N = 8.
зв,с
Число локальных звеньев N =64 (рис. 5).
Общее число слоев N = 5 256, а общая длина
слоев '
ОМСР равна (У4)^ = 3 942 мкм ~ 4 мм.
г 4 0 7 слоев
В статье рассмотрен новый метод синтеза амплитудных корректоров, основанный на применении оптических многослойных решеток. Разработаны оба этапа процедуры синтеза: решение задач аппроксимации и реализации. Пример расчета локального корректора амплитудных искажений подтверждает прикладную значимость основных теоретических положений статьи.
список литературы
1. Лапшин, Б.А. Новая теория и расчет фильтров и трансформаторов на отрезках передающих линий [Текст]/ Б.А. Лапшин. -СПб.: Наука, 1998. -175 с.
2. Белецкий, А.Ф. Теоретические основы электропроводной связи: Ч. 3. [Текст]/ А.Ф. Белецкий. -М.: Связьиздат, 1959. -390 с.
3. Ланнэ, А.А. Оптимальный синтез линейных электронных схем [Текст]/ А.А. Ланнэ. -М.: Связь,1978. -336 с.
4. Фриман, Р. Волоконно-оптические системы связи [Текст]/ Р. Фриман; пер. с англ. -М.: Техносфера, 2003. -440 с.
5. Слепов, Н.Н. Современные технологии цифровых оптоволоконных сетей связи [Текст]/ Н.Н. Слепов. -М.: Радио и связь, 2003. -300 с.
6. Lapshin, B.A. Synthesis of high frequency wave
filters and transformers for communication systems [Text]/ B.A. Lapshin// 1* IEEE Int. Conf. On Circuits and Systems for Communications. -SPb, 2002. -P. 7.
7. Lapshin, B.A. Synthesis of wave analogue super narrou band filters [Text]/ B.A. Lapshin, V.A. Petrakov, A.V. Fedorov // ETV-05, The 7th Emering Workshop: Circuit and Systems for 4G Mobile Wireless Communications. -SPb, 2005.
8. Арасланкин, И.Ф. Многоканальные системы передачи [Текст]/ И.Ф. Арасланкин, Б.А. Лапшин, А.Я. Макаренко. -СПб.: ВАС, 2007.-672 c.
9. Френкс, Л. Теория сигналов [Текст]/ Л. Френкс. -М.: Сов. радио, 1974. -344 c.
10. Лапшин, Б.А. Синтез оптических многослойных фильтров [Текст]/ Б.А. Лапшин, В.А. Петраков. // Компоненты и технологии. -СПб. -2006. -№ 10. -C. 50-55.
УДК 004.4+004.7
Ю.А. Богоявленский, А.С. Колосов
организация и автоматизированная поддержка объектной базы данных графа икт-инфраструктуры
поставщика услуг интернета
Интенсивное развитие аппаратуры и си- инфраструктур (далее - Сеть) поставщиков сете-стемного прогрммного обеспечения (ПО) ИКТ- вых услуг (ПСУ) требует расширения исследо-
ваний в области сетевого управления. В [1] говорится: «В настоящее время сетевое управление характеризуется недостатком информации о статусе и работоспособности сетей, лавиной данных (объемных, неоднозначных, неполных и противоречивых одновременно) и грубыми или неточными управляющими механизмами, чье воздействие трудно предсказуемо. ... Для изменения сегодняшнего статус кво необходимы глубокие исследования в области сетевого управления».
Авторы [2] также обосновывают необходимость разработки формальных методов анализа сетей и экспериментальных платформ (ЭП, англ. термин testbed), обеспечивающих выполнение убедительных эталонных тестов в условиях реалистичных рабочих процессов. В [3] дан обзор широкого спектра ЭП.
Разрабатываемая в Петрозаводском государственном университете (ПетрГУ) ЭП Nest [4] предназначена для исследования моделей и методов управления Сетями на основе развивающейся и стандартизованной IETF измерительной технологии потоков данных [5, 6], которая широко используется для решения различных задач сетевого управления [7].
В зависимости от уровня (tier), ПСУ выполняют существенно различные функции в Интернет и, следовательно, характеристики и архитектура их Сетей имеют отличия, которые необходимо учитывать при разработке ЭП. Платформа Nest ориентирована на ПСУ, находящиеся по классификации [8], представленной в табл. 1, на третьем и четвертом уровнях (лПСУ).
Сети лПСУ принадлежат организациям средней величины и имеют небольшое число пограничных маршрутизаторов, обеспечивающих связь с Интернет. лПСУ ближе всех к пользователям, их основная функция - поставка услуг своему персоналу. Усложнение Сетей лПСУ (в англ. терминологии - Enterprise Networks) привело к существенному расширению исследований [9]
Таблица 1 Классификация уровней ПСУ
Номер и название уровня Кол-во ПСУ
0. Плотное ядро 20
1. Транзитное ядро 129
2. Внешнее ядро 897
3. Малые региональные ПСУ 971
4. Локальные ПСУ 8898
ориентированных на них методов управления и проектирования.
Данные об аппаратных элементах Сети и их связях (далее - граф Сети) являются базовым инструментом систем сетевого управления и ЭП. Знание актуального графа Сети позволяет идентифицировать формальные модели поведения входящих, исходящих и внутренних потоков данных, разрабатывать модели и методы решения большинства задач представленной ISO функциональной модели FCAPS. Например, задача планирования мощности лПСУ часто решается с помощью имитационных моделей, также использующих граф Сети [7].
Графы Сети современных лПСУ содержат тысячи элементов и связей, существенно меняются во времени, поэтому для их использования необходима система автоматизированного построения и хранения в БД.
Новым в представленном подходе является организация БД на основе объектной модели графа Сети, которая связана с объектными моделями организационной и пространственной структур лПСУ, что позволяет связывать узлы графа Сети с элементами этих структур в единой БД архитектуры организации, владеющей лПСУ.
В ЭП Nest граф Сети строится подсистемой Nestopo, которая, в отличие от предыдущих работ, не только обнаруживает, получая данные из таблиц MIB по протоколу SNMP, аппаратные элементы сети и связи между ними, но и размещает данные о графе в БД и поддерживает их актуальность.
Организация объектной базы данных графа Сети лПСУ
В статье предлагается для описания графа Сети использовать объектно-ориентированную модель данных, классы которой описывают множества возможных узлов и связей между ними. Порождаемые классами модели объекты, соответствующие узлам актуального графа Сети, определяются путем опроса данных MIB маршрутизаторов по протоколу SNMP.
Поведение потоков данных зависит от технических характеристик Сети и от поддерживаемых ею бизнес-процессов. Поэтому граф Сети должен отражать не только связи аппаратных элементов между собой, но и их связи с пространственными и административными единицами организации, владеющей лПСУ.
Рис. 1. Архитектура организации, владеющей лПСУ
Такие модели разрабатываются в рамках активно развиваемого подхода интегрированного моделирования архитектуры организации в целом (ИМАП - IEM - Integrated Enterprise Modeling), когда Сеть рассматривается как подсистема организации. Для реализации ИМАП разработаны опорные среды [10], стандарты [11], программные инструменты и, содержащие сотни классов, объектные модели данных CIM, SID [12], основанные на базовых стандартах ITIL и TOGAF.
Сложность этих моделей затрудняет их использование при разработке ЭП, поэтому модель данных строится на основе представленной на рис. 1 схемы архитектуры организации, владеющей лПСУ. Сеть располагается в пространстве нескольких зданий, при этом ее элементы обслуживают различные структурные единицы.
В работе используется простая трехструктур-ная объектно-ориентированная модель данных SON [4], являющаяся композицией трех моделей подсистем архитектуры лПСУ - пространственной (S - Spatial), организационной (O -Organizational) и аппаратно-сетевой (N - Network). Модель представлена на рис. 2 а в нотации UML. Класс Occupancy связывает три модели, описывая часть помещения, которое принадлежит одной
организационной единице и содержит определенные устройства. Введение этого класса позволило избежать неудобных для реализации связей «многие ко многим».
SON позволяет как идентифицировать потоки данных через элементы этих компонент и агрегации элементов, так и, при необходимости, связывать эту модель с более сложными моделями архитектуры организации.
N-компонента модели SON - простая (8 классов) модель графа Сети (рис. 2 б), построеная согласно следующим требованиям: простота, расширяемость; явная связь с моделями организационной и пространственной подсистем лПСУ;
идентификация всех аппаратных источников и приемников потоков данных;
представление узлами графа Сети как элементарных (устройства), так и агрегированных (IP-подсети, виртуальные сети VLAN) источников и приемников потоков данных;
представление связи между узлами на уровне маршрутов IP;
характеризация элементарных узлов IP и MAC-адресами;
возможность подключения алгоритмов построения графа канального уровня Сети.
а)
Рис. 2. Модель SON: а - общая модель SON; б - N-компонента модели SON
В N-компоненте узлы графа на сетевом уровне представлены классами, описывающими устройства, IP-интерфейсы и IP-подсети. На канальном уровне - канальные интерфейсы и их связи между собой. Устройство, имеющее IP-адрес, описывается классом Device, его интерфейсы канального уровня - классом LinkInterface. Каждому интерфейсу канального уровня может назначаться несколько интерфейсов сетевого уровня (Networklnterface), которые могут быть объединены в IP-подсети (класс IPNetwork - наследник класса Network). Наследниками класса LinkInterface являются классы VLANInterface и EthernetInterface. Класс IPv4Interface является наследником класса NetworkInterface. При этом класс VLANInterface агрегирует входящие в виртуальную сеть объекты класса LinkInterface.
Узлы графа Сети представляются конкретными объектами классов модели. Дуги графа считаются ненаправленными, строятся согласно связям между классами и содержательно интерпретируются по конкретному техническому смыслу этих связей, как это показано на рис. 3. Маршрутизатор D1 имеет канальные интерфейсы LI1, LI2, LI3. Последние два объединены в виртуальную
сеть V1, имеющую сетевой интерфейс NI1, принадлежащий подсети N2.
Алгоритм автоматизированной поддержки базы данных графа Сети
В англоязычной литературе рассматривалась задача «обнаружения топологии» (topology discovery) или построения «карты сети» (network mapping), вне связи с задачей хранения этих данных в БД. Наш алгоритм реализует задачу обнаружения совместно с задачей размещения в БД актуальных данных о графе Сети.
В ранних работах по алгоритмам обнаружения использовались такие инструменты, как ICMP (ping, traceroute), DNS. В 1999 г. в [13] предложен один из первых алгоритмов обнаружения топологии на уровне IP на основе данных MIB маршрутизаторов сети, поддерживаемых протоколом SNMP. Далее этот подход интенсивно развивался, и в [14] приведен обзор его современного состояния и предложен алгоритм обнаружения топологии на канальном и IP уровнях, а также сервисов на уровнях 4 и 7 модели OSI.
Отметим, что интенсивное развитие технологий канального уровня [15] и разнообразие
Рис. 3. Пример графа Сети в виде UML-диаграммы объектов
политик доступа к данным SNMP существенно усложняют алгоритмы построения графа Сети этого уровня. Разработку таких алгоритмов целесообразно вести на основе недавно стандартизованного протокола LLDP [16], специально разработанного для этих целей.
В алгоритме (рис. 4) представлен процесс построения графа Сети и записи его в объектную БД. На вход алгоритма подаются IP-адрес произвольного маршрутизатора лПСУ и параметры обращения по протоколу SNMP. Используются объекты MIB маршрутизаторов ifTable, ifXTable, ipAddrTable, ipNetToMediaTable, ipRouteTable и некоторые др.
Работа начинается с создания узла Device, описывающего начальный маршрутизатор. Затем из его MIB запрашивается таблица канальных интерфейсов ifTable и для каждого ее элемента создается узел LinkInterface и его связи с маршрутизатором. По данным таблицы сетевых адресов ipAddrTable для каждого узла LinkInterface создаются узлы назначенных ему сетевых интерфейсов - конкретных наследников класса Net-
worklnterface (например IPv4Interface) и соответствующие связи. Затем, для каждого сетевого интерфейса с помощью маски подсети определяется ее адрес, создается узел подсети IPNetwork и его связь с узлом этого сетевого интерфейса.
Множество других сетевых интерфейсов, входящих в подсеть, описываемую созданным на предыдущем шаге узлом, определяется путем выбора из таблицы ipNetToMediaTable (ARP-кеш) записей устройств, IP-адреса которых входят в эту подсеть. Создаются узлы этих устройств, их канальных и сетевых интерфейсов, а также все необходимые связи между узлами.
Устройство, имеющее значение indirect в поле ipRouteNextHop таблицы ipRouteTable, выполняет маршрутизацию. Если к нему есть доступ по SNMP, то к представляющему его узлу применяется описанный выше алгоритм. В противном случае по данным полей таблицы ipRouteNextHop определяются подсети, получающие пакеты через это устройство, создаются соответствующие им узлы и их связи.
Перед созданием узла графа по атрибутам
Рис. 4. Схема алгоритма построения графа Сети
объекта производится поиск для проверки при- Отметим, что проверка присутствия узлов
сутствия этого узла в БД. В случае присутствия в БД позволяет корректно представлять устрой-
атрибуты и связи обновляются, иначе - создают- ства, имеющие несколько сетевых адресов
ся, после чего они записываются в БД. (multihoming). При обнаружении устройства вы-
полняется поиск созданных ранее объектов класса Linklnterface с MAC-адресом обнаруженного устройства. Если такой объект найден, то набор его сетевых интерфейсов обновляется.
В настоящее время разработка универсального алгоритма получения данных об идентификаторе виртуальной сети и наборах входящих в нее канальных интерфейсов затруднена использованием закрытых корпоративных стандартов и другими недостатками в реализациях соответствующих MIB. В представленном алгоритме методы получения данных выбираются в зависимости от типа маршрутизатора. Для маршрутизатора Cisco 7204 VXR набор канальных интерфейсов, соответствующих виртуальному, получается из стандартной таблицы ifStackTable.
В маршрутизаторах Cisco 1841 и Cisco Catalyst 37xx используются таблицы vmMembershipTable из MIB-модуля CISCO-VLAN-MEMBERSHIP-MIB, cviVlanlnterfacelndexTable из MIB-модуля CISCO-VLAN-IFTABLE-RELATIONSHIP-MIB.
Подсистема Nestopo для построения и заполнения БД графа Сети
БД реализована следующим образом. Конечным хранилищем графа является реляционная
СУБД. Для выполнения базовых операций (чтение, запись, поиск) в терминах объектного представления используется технология объектно-реляционного отображения Java Persistence API (JPA), реализованная в программном каркасе Hibernate. Генерация реляционной схемы, соответствующей объектной модели SON выполняется Hibernate автоматически. Запросы формулируются на языке JPQL и автоматически транслируются в SQL-запросы к нижележащей реляционной БД. Результатом запроса является набор объектов SON-модели, удовлетворяющих заданным условиям. Hibernate поддерживает более 25 различных реляционных СУБД. В настоящий момент Nest использует MySQL и Apache Derby.
Архитектура подсистемы Nestopo (рис. 5) основана на принципе изоляции кода. Для каждого класса модели графа Сети разработан независимый от других классов модели программный класс — провайдер, реализующий построение объектов этого класса. Такой подход существенно облегчает модификацию кода при изменениях модели графа Сети и процедур его построения и обеспечивает возможность частичного обновления БД.
Рис. 5. UML-диаграмма классов подсистемы Nestopo
Рис. 6. Иллюстрация работы классов-провайдеров подсистемы Nestopo
Подход реализован с использованием паттернов проектирования «Издатель-Подписчик» [17] (реакция на обращение к SON-элементу) и «обращение управления» (inversion of control) [18] (выполнение построения объекта в момент обращения к нему).
Все объекты SON-модели (наследники класса SonElement) выступают в роли издателя уведомлений о событиях обращения к своим атрибутам. При создании в ходе алгоритма нового SON-элемента, создается также соответствующий провайдер (наследник класса NElementProvider), который подключается к создаваемому узлу в качестве подписчика. При получении уведомления провайдер начинает сбор данных для заполнения атрибутов SON-элемента.
Рассмотрим пример. При первом обращении к атрибутам объекта, описывающего корневой маршрутизатор (рис. 6 а), провайдер Rou-terProvider устанавливает SNMP-соединение, определяет значения атрибутов устройства и создает связи с пустыми узлами класса LinkInterface. На следующем этапе (рис. 6 б) провайдеры класса LinkLiProvider определяют значения атрибутов канальных интерфейсов и их связи. Далее (рис. 6 в, г) аналогичным образом строятся узлы сетевых интерфейсов, подсетей и принадлежащих им устройств.
Алгоритмы определения конфигурации VLAN маршрутизатора реализованы в наследниках абстрактного класса VlanInfoSupplier, результат их работы доступен посредством объекта класса VlanDB.
Представленная реализация позволяет обновлять БД графа Сети без полного перестроения, что позволяет вести учет изменений графа. Ак-
туальность данных в БД обеспечивается за счет периодических запусков подсистемы.
Nestopo реализована на платформе Java. Для доступа к MIB по протоколу SNMP используется библиотека SNMP4J. Для вызова процедуры обновления БД реализован интерфейс командной строки. Исходный код представлен в 42 файлах, содержит 55 классов (из них 11 анонимных), 2774 LOC.
Тестирование и эксперименты
Цель экспериментов - получение оценок времени построения графа, объема порождаемого сетевого трафика, адекватности получаемого графа. Выполнено построение графа для различных участков вычислительной сети ПетрГУ: 1) ЛВС кафедры информатики и математического обеспечения (один опрашиваемый маршрутизатор); 2) ЛВС учебных корпусов ПетрГУ (два маршрутизатора); 3) вся вычислительная сеть ПетрГУ (три маршрутизатора).
Результаты эксперимента приведены в табл. 2. В первой колонке указан номер участка сети, во второй - количество обнаруженных устройств, в третьей и четвертой - общее время работы подсистемы и время работы алгоритма построения графа Сети без учета времени, затраченного на сетевое взаимодействие и обращения к маршрутизаторам, не поддерживающим SNMP, в пятой и шестой колонках - объем сетевого трафика, потребовавшегося для получения данных от маршрутизаторов. Все построенные графы соответствовали данным системных администраторов о реальном графе Сети.
Подсистема Nestopo используется сотрудниками вычислительного центра ПетрГУ совместно
Табл ица 2
Результаты тестирования подсистемы для различных конфигураций (Intel Xeon 2.50 ГГц, ОЗУ 1 Гб, ОС Linux 2.6.34, JRE 1.6.0_23)
№ Количество устройств Время выполнения, с Время построения графа, с Исходящий трафик, Кб Входящий трафик, Кб
1 38 12 5,8 5,44 19,29
2 1359 47 32,6 38,97 244,05
3 1454 73 34,9 66,84 407,63
с системой обнаружения вторжений для решения задач управления безопасностью. При получении уведомления о вредоносной активности на каком-либо из узлов сети инженер обращается к ЭП Nest для получения сведений об этом узле, его местонахождении и административной принадлежности.
Представленные в статье метод организации объектной БД и алгоритм обеспечивают автоматизацию обнаружения графа сети ИКТ-инфраструктуры локальных и малых региональных поставщиков услуг Интернет и связей между ними на сетевом уровне с поддержкой базовых данных канального уровня и виртуальных сетей.
Включение объектной модели графа Сети в объектную модель архитектуры организации обеспечивает базу для совместного исследования потоков данных через аппаратные, административные и пространственные единицы организации и их агрегации.
Разработанная подсистема Nestopo обеспечивает автоматическое формирование БД графа Сети и поддержку ее в актуальном состоянии.
списокл
1. Cerf, V. FIND Observer Panel Report [Электронный ресурс] / V. Cerf, B. Davie, A. Greenberg [et al.]// Tech. rep.: NSF NeTS FIND Initiative. -Apr. 2009. Режим доступа: http://www.nets-find.net/FIND_report_final.pdf
2. Al-Shaer, E. New Frontiers in Internet Network Management [Текст] / E. Al-Shaer, A. Greenberg, C. Ka-lmanek [et al.] // Computer Communication Rev. -Oct. 2009. -Vol. 39. -P. 37-39.
3. Report of NSF Workshop on Network Research Testbeds [Электронный ресурс]/ -Nov. 2002. Режим до ступа: http://www-net.cs.umass.edu/testbed_workshop/ testbed_workshop_report_final.pdf
4. Богоявленский, Ю.А. Проект Nest: структурное представление системы поставщика сетевых услуг [Текст] / Ю.А. Богоявленский, М.А. Крышень, А.С. Ко-
При изменении графа соответствующее частичное обновление БД выполняется без ее полного перестроения.
Экспериментальная эксплуатация подсистемы Nestopo показала ее хорошую производительность. Формирование БД графа Сети, содержащей более тысячи устройств, требует около одной минуты при незначительном потреблении сетевого трафика.
В будущем предполагается провести широкое экспериментальное исследование алгоритма для обоснования его надежности и эффективности на количественном уровне. Также будут предприняты усилия для получения формальной стратегии выполнения повторных запусков подсистемы, обеспечивающей актуальность БД; ЭП Nest будет опубликована в виде ПО с открытым кодом, в алгоритм предполагается включить процедуры построения графа канального уровня Сети.
Авторы благодарят М.А. Крышеня за полезные идеи и обсуждения, В.А. Пономарева за системную поддержку, И.О. Суворова и И.А. Зиновика за помощь в выполнении экспериментов. Особая благодарность рецензенту, замечания которого помогли существенно улучшить качество данной статьи.
лосов [и др.] // Матер. межвуз. конкурса-конф. студентов, аспирантов и молодых ученых Северо-Запада «Технологии Microsoft в теории и практике программирования». -СПб.: Изд-во СпбГПУ, 2008. -С. 49-51.
5. Claise, B. Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information. RFC 5101 [Текст] / B. Claise. -IETF, 2008.
6. Cisco IOS NetFlow - Cisco Systems [Электронный ресурс] / Режим доступа: http://www.cisco.com/go/net-flow
7. Claise, B. Network Management: Accounting and Performance Strategies [Текст] / B. Claise, R. Wolter. -Cisco Press, 2007. -P. 631.
8. Subramanian, L. Characterizing the Internet Hierarchy from Multiple Vantage Points [Текст] / L. Sub-
ramanian, S. Agarwal, J. Rexford [et al.] // Tech. Rep. UCB/CSD-1-1151. California: Computer Science Division (EECS) University of California Berkeley, Aug. 2001. -P. 12.
9. Proc. of USENIX INM/WREN'10 [Электронный ресурс]/ -2010. Режим доступа: http://www. usenix.org/ event/inmwren10/techl
10. Leist, S. Evaluation of Current Architecture Frameworks [Текст] / S. Leist, G. Zellner // Proc. of SAC'06. -Dijon, France, 2006. -P. 1546-1553.
11. Enterprise integration - Framework for enterprise modelling. ISO 19439:2006 [Текст]. -ISO, Geneva, Switzerland, 200б.
12. Brenner, M. CMDB - Yet Another MIB? On Reusing Management Model Concepts in ITIL Configuration Management [Текст] / M. Brenner, M. Garschhammer, M. Sailer [et al.] // Proc. of 17th IFIP/IEEE International Workshop on Distributed Systems: Operations and Management (DSOM 06). -Springer, 2006. -P. 269-280.
13. Siamwalla, R. Discovering internet topology [Электронный ресурс] / R. Siamwalla, R. Sharma, S. Ke-shav// Режим доступа: http://www.cs.cornell.edu/skeshav/ papers/discovery.pdf
14. Pandey, S. IP network topology discovery using SNMP [Текст] / S. Pandey, M.-J. Choi, S.-J. Lee [et al.] // Proc. of the 23 rd International conf. on Information Networking. -IEEE Press, 2009. -P. 33-37.
15. Vaez-Ghaemi, R. White Paper. Next-Generation Packet-Based Transport Networks (PTN) [Электронный ресурс] / R. Vaez-Ghaemi // Tech. rep.: JDS Uniphase Corporation, 2010. Режим доступа: http://www.jdsu.com/ ProductLiterature/ next-generation-ptn-white-paper. pdf
16. IEEE Standard for Local and metropolian area networks - Station and Media Access Control Connectivity Discovery. IEEE Std 802.1AB-2009 [Текст]. -IEEE, 2009.
17. Гамма, Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования [Текст] / Э. Гамма, Р. Хелм, Р. Джонсон [и др.]. -СПб.: Питер, 2001. -368 c.
18. Fowler, M. Inversion of Control Containers and the Dependency Injection pattern [Электронный ресурс] / M. Fowler. -Режим доступа: http://www.martinfowler. com/articles/injection.html
