Содержание к диссертации
Введение
ГЛАВА 1. Определение моделей для управления трафиком ір телефонии в мультимедийном контенте 9
1.1. Требования для создания адекватных моделей эффективного управления мультимедийным трафиком 9
1.2. Характеристики трафика ІР-сетей 11
1.3. Оценочные показатели и методы достижения качества ІР-телефонии . 13
1.4. Архитектура протоколов мультимедийной связи 15
1.5. Параметризованная модель передачи трафика ІР-телефонии для имитационного моделирования 20
1.5.1. Математическая модель источника VoIP-трафика 20
1.5.2. Параметры голосовых кодеков и структура пакета данных 22
1.5.3. Математическая модель TCP-нагрузки 26
1.5.4. Структури; з лодели генератора источника VoIP-пакетов и web-сеанса 1.6. Типовые имитационные модели топологий, актуальные для Интернет-провайдера 31
1.7. Формализованные модели качества ІР-телефонии и ее показателей...
1.7.1. Е-модель определения качества голосового трафика 33
1.7.2. Математическая модель процесса потерь пакетов 35
1.8. Выводы 37
ГЛАВА 2. Исследование и разработка алгоритмов превентивного предотвращения перегрузки для мультимедийного трафика 38
2.1. Проблема переполнения очередей в маршрутизаторах 38
2.1.1. Методы борьбы с перегрузками в ІР-сетях 38
2.1.2. Влияние механизма сброса хвоста очереди на работу протокола TCP 42
2.2. Обзор алгоритмов активного управления очередью 43
2.2.1. Алгоритм RED 44
2.2.2. Алгоритм СНОКе 47
2.2.3. Устойчивый RED (SRED) 48
2.2.4. Алгоритм BLUE 49
2.2.5. Адаптивный RED (ARED) 50
2.2.6. RED-Boston - вариант управления очередью с учетом задержки... 51
2.2.7. Имитационное моделирование семейства RED-алгоритмов 52
2.3. Разработка алгоритма превентивного предотвращения перегрузки rtRED для мультимедийного трафика 53
2.3.1. Постановка задачи 53
2.3.2. Описание алгоритма rtRED 56
ГЛАВА 3. Разработка программы и сценариев имитационного моделирования трафика ІР-телефонии 58
3.1. Выбор программного обеспечения для имитационного моделирования мультимедийного трафика 58
3.2. Параметрическая имитационная модель для исследования трафика пакетной телефонии мультисервисной сети 61
3.2.1. Модель нагрузки 61
3.2.2. Модели топологии и управления 64
3.3. Построение программного имитационного стенда ІР-телефонии и проведение моделирования трафика мультисервисной сети 68
3.3.1. Архитектура имитационного программного комплекса 68
3.3.2. Типовые сценарии моделирования 70
3.4. Натурные измерения характеристик трафика ІР-телефонии и оценка адекватности имитационной модели 75
3.4.1. Методика оценки адекватности имитационной модели для сети с КО 3.4.2. Технология получения выборок экспериментальных данных 79
ГЛАВА 4. Создание единой операторской и корпоративной мультисервисной сети для научных исследований 85
4.1. Методология построения Открытой Корпоративной Сети (ОКС) РФЯЦ ВНИИТФ 85
4.1.1. Предпосылки и история создания ОКС ВНИИТФ 85
4.1.2. Уровневая и зоновая модели ОКС ВНИИТФ 88
4.2. Разработка и анализ системы управления ІР-телефонией 92
4.2.1. Компоненты системы управления ІР-телефонией 92
4.2.2. Анализ внедрения и использования ІР-телефонии в ОКС ВНИИТФ97
Заключение 101
Список литературы
- Оценочные показатели и методы достижения качества ІР-телефонии
- Влияние механизма сброса хвоста очереди на работу протокола TCP
- Построение программного имитационного стенда ІР-телефонии и проведение моделирования трафика мультисервисной сети
- Разработка и анализ системы управления ІР-телефонией
Оценочные показатели и методы достижения качества ІР-телефонии
Два наиболее полно специфицированных подхода к построению сетей IP-телефонии предложены международным союзом электросвязи (ITU) в архитектуре Н.323 [70] и в стандарте на базе протокола SIP, выработанного рабочей группой MMUSIC комитета IETF [116].
Архитектура Н.323 является более ранней разработкой, которая широко поддержана основными производителями оборудования ІР-телефонии. Первая версия стандарта была предложена в 1996г., а вторая - в 1998г. В состав сети Н.323 входят логические компоненты-устройства (терминал, шлюз, гейткипер, устройство управления конференциями) и протоколы, обеспечивающие взаимодействие этих компонент. Рис.4 показывает (аналогично предыдущему рисунку, но в горизонтальной плоскости) слои архитектуры Н.323 с аббревиатурами протоколов, входящих в данный стандарт. Кроме протоколов Н.323 стандартизовал некоторые важные кодеки для голоса и видео.
Второй подход основан на использовании байт-ориентированного протокола инициирования сессий - SIP (Session Initiation Protocol). Протокол SIP может работать в тандеме с протоколом SDP (Session Description Protocol) [114]. SIP-архитектура является достаточно перспективной - она принята и поддерживается Интернет-сообществом. H.Schulzrinne и J.Rosenberg в [121] проведено сравнение возможностей архитектур Н.323 и SIP с некоторыми выводами в пользу последней.
Протоколы MEGACO (Media Gateway Control) [117] и RTSP (Realime Streaming Protocol) [113] являются более частными предложениями. MEGACO отвечает за управление шлюзами между сетью ІР-телефонии и телефонной сетью общего пользования (ТфОП) и является протоколом сигнализации, а клиент-серверный протокол RTSP разработан для улучшения управления потоковыми аудио-и видео- приложениями (например, широковещательной трансляцией передач Интернет-радиостанций).
К универсальным сетевым архитектурам, обеспечивающим гарантированное качество передачи данных, относится архитектура на базе протокола резервирования ресурсов RSVP [112], называемая архитектурой интегрированных услуг [108]. Основная задача протокола и всей архитектуры - описать сетевые службы и требования КО для каждой из них. Это означает, что RSVP предназначается для сквозного распределения сетевых ресурсов между отдельными потоками трафика. Принципиальными недостатками протокола RSVP являются два момента: неэффективное использование каналов и большая нагрузка на маршрутизаторы при увеличении числа сессий. Данная архитектура, построенная на принципе избыточности, является чрезвычайно дорогим решением с точки зрения эффективности использования ресурсов сети. Поэтому ее применение в российских сетях пока мало перспективно. Следует отдельно упомянуть о других архитектурах обеспечения КО, которые не входят в структуру протоколов мультимедийной связи, но которые являются более перспективными для передачи мультимедийного контента.
Первый подход, который начинается реализовываться в сетях Интернет, строится на модели дифференциации услуг [115]. Модель базируется на использовании байта ToS (Type of Service) протокола IP, который именуется DS, а шесть его битов отведены для кода Diff-Serv. Каждому значению этого кода соответствует свой класс пересылки РНВ, определяющий ожидаемый уровень обслуживания. В рамках каждого класса пакеты должны обрабатываться в соответствии с определенными для него требованиями к КО. Трафик разделяется на ограниченное число классов, что обеспечивает возможность масштабируемой дифференциации услуг. Модель Diff-Serv описывает архитектуру сети как совокупность пограничных участков и ядра сети. Поступающий в сеть трафик классифицируется и нормируется пограничными маршрутизаторами. Нормирование трафика предусматривает измерение его параметров, проверку соответствия заданным правилам предоставления услуг, профилирование (при этом пакеты, не укладывающиеся в рамки установленных правил, могут быть отсеяны) и другие операции. В ядре сети магистральные маршрутизаторы или коммутаторы пересылают трафик в соответствии с классом РНВ, код которого указан в поле DS. Достоинства модели Diff-Serv состоят в том, что она, во-первых, обеспечивает единое понимание того, как должен обрабатываться трафик определенного класса, а во-вторых, позволяет разделить весь трафик на относительно небольшое число классов вместо того, чтобы отдельно анализировать каждый поток.
Другой архитектурой, уже начавшей внедряться в российском Интернете, является технология мультипротокольной коммутации меток (MPLS), также стандартизованная Интернет-сообществом. В ее основе лежит принцип отображения сетевых адресов на специальные метки, которые могут использоваться для пересылки пакетов. В обычных IP-сетях каждый маршрутизатор, находящийся на пути следования трафика, анализирует все пакеты для выявления потоков, к которым они относятся. При использовании технологии MPLS соответствие между конкретным пакетом и потоком устанавливается один раз, на входе в сеть MPLS. При этом поток маркируется коротким идентификатором фиксированной длины - меткой. Далее пакет передается вместе с меткой. Это значительно упрощает процедуру обработки пакетов (по сравнению с традиционной маршрутизацией). Первоначально основным достоинством технологии MPLS считалось то, что она позволяет значительно ускорить процессы пересылки трафика за счет применения высокоскоростных средств коммутации. Однако, сегодня технология MPLS с успехом используется и для высокоскоростной классической ІР-маршрутизации (например, в магистралях сетей Ростелеком и Транстелеком). Изменилось и позиционирование технологии MPLS - в настоящее время ее рассматривают в первую очередь как эффективное средство для управления качеством обслуживания и инжиниринга трафика. Основное отличие технологии MPLS от протокола RSVP заключается в том, что она обеспечивает установление сквозного пути передачи потока, своего рода виртуального соединения. При этом отдельные потоки могут агрегироваться в классы, что позволяет достичь высокой масштабируемости и обеспечить согласованное управление трафиком, в том числе и телефонным.
Вернемся к обзору протоколов на Рис.3. Для передачи пакетов с интерактивным голосом в сетях ІР-телефонии используется протокол RTP (Realime Transport Protocol) [109]. Этот протокол не обеспечивает функции управления потоком, которые обычно предоставляют транспортные протоколы. Основная задача RTP заключается в вычислении средней задержки в последовательности принятых пакетов, ее сглаживание и выдача пакетов пользовательскому приложению с постоянной задержкой, равной этому среднему значению. При обосновании требований к качеству передачи пакетизированного голоса ниже будет показана важность этой функции протокола RTP. Протокол работает поверх простого транспортного протокола UDP, который, как известно, в отличие от TCP не организует соединение между отправителем и получателем и поэтому более эффективен при передаче трафика реального времени, хотя и не обеспечивает гарантии доставки. Таким образом, голосовые пакеты в IP-сетях передаются в составе протокольной триады RTP/UDP/IP.
Доставка RTP-пакетов контролируется специальным протоколом RTCP (Real Time Control Protocol). Цель использования протокола RTCP состоит в организации обратной связи приемника с отправителем информации для отчета о качестве получаемых данных. Протокол RTCP измеряет и передает отправителю сведения о текущем состоянии сеанса передачи (количество потерянных пакетов, время задержки при передаче и др.). Эта информация может быть использована отправителем для применения адаптивных алгоритмов изменения параметров передачи [26].
Сразу следует поставить исследуемую нами проблему в определенные рамки. Во-первых, построение имитационной модели передачи трафика в мультисервисной сети на базе сквозных архитектур (Intserv, Diffserv, MPLS), которые упоминались в этом обзоре, не входит в задачу диссертационной работы. Наша цель состоит в создании имитационного стенда для обычного оператора Интернет или корпоративного клиента, использующих типовое оборудование и единые каналы (например, типа ethernet) для передачи мультимедийного контента. Данная задача более актуальна для нужд рядового провайдера или организации, которая хочет использовать и оптимизировать построенную ими сетевую инфраструктуру не только для передачи данных и доступа в Интернет, но и для корпоративной ІР-телефонии или широковещательной трансляции видео потоков. Во-вторых, вопросы моделирования протоколов телефонной сигнализации и фазы установки соединений для ІР-телефонии также выходят за рамки данного исследования, т.к. эти моменты больше важны для крупных операторов ІР-телефонии, которые могут иметь непредсказуемую нагрузку на количество одновременно поддерживаемых телефонных соединений. В корпоративной сети среднее количество вызовов ІР-телефонии в сек. всегда контролируемо и не подвержено сильным колебаниям. Поэтому разработчиком сети легко вычисляется количество портов-каналов телефонного шлюза, необходимое для эксплуатации услуги без риска возникновения занятости голосовых каналов.
Влияние механизма сброса хвоста очереди на работу протокола TCP
Данное состояние характеризуется низкой задержкой и отсутствием потерь пакетов. В точке А начинается фаза перегрузки, когда приложения стремятся захватить основную ширину пропускания канала. В этой фазе нарастает задержка и маршрутизатор начинает сбрасывать пакеты. До точки В характеристики всех процессов, относящихся к показателям КО, ухудшаются относительно равномерно. В точке В происходит резкое падение производительности канала, которая (при добавочном увеличении интенсивности входных потоков) может снизиться почти до нуля (точка С). Основная цель методов борьбы с перегрузками ориентирована на недопущение возникновения третьей фазы перегрузки, либо на оттягивание времени ее наступления только до момента чрезмерной загрузки канала.
Рассмотрим природу возникновения сетевых перегрузок. По мере загрузки пакетной IP-сети, которая использует принцип повторной передачи пакетов, время на их передачу и подтверждение (называемое roundrip time, RTT) начинает увеличиваться, а соответственно растет и количество транзитных, еще не подтвержденных дейтаграмм. До тех пор, пока в транзите находится только одна копия каждого пакета - перегрузка управляема. Проблему может вызвать ретрансляция дейтаграмм, которые еще не доставлены и находятся в транзите. Типовые реализации протокола TCP предполагают повторные передачи пакетов через увеличивающиеся интервалы времени, пока не будет достигнут некоторый верхний временной пороговый предел. В нормальной ситуации данный механизм проявляет себя достаточно эффективно. Однако, даже с улучшенными, адаптивными алгоритмами ретрансляции пакетов, реализованных в последних версиях протокола TCP, сильный всплеск загрузки сети может вызвать следующую ситуацию: время на передачу и подтверждение приема начинает расти быстрее, чем передающий компьютер успевает замерять и обновлять это время у себя. Как только значение RTT превысит максимальный временной интервал ретрансляции для источника нагрузки, этот источник начнет посылать все больше и больше копий одной и той же дейтаграммы. При этом доступные буферы в маршрутизаторах будут быстро заполнены, и все пребывающие пакеты начнут сбрасываться. Т.е. сеть войдет в 3-ю фазу перегрузки, в состояние коллапса. Отметим, что состояние коллапса устойчиво. Если алгоритм управления буферизацией равноправно относится ко всем типам трафика, тогда сеть продолжит функционировать в состоянии частичной работоспособности. В этом состоянии каждый пакет будет ретранслироваться по несколько раз, а общая утилизация сети составит малую часть от пропускной способности каналов. TCP-соединения будут разрываться по тайм-аутам. Поэтому мультимедиа-приложения реального времени избегают пользоваться услугами TCP, т.к. этот протокол чувствителен к пульсациям трафика. Ретрансляции потерянных данных приводит к ухудшению качества мультимедиа из-за возрастания задержки и джиттера. Вместо TCP обычно используется транспортный протокол UDP. Однако это решение также имеет свои минусы. Протокол UDP не адаптивен к потерям пакетов и перегрузкам.
Мы сконцентрируемся на исследовании методов управления очередями в условиях перегрузки с ориентацией на обслуживание мультимедийных приложений. Следует отметить, что множество промышленно реализованных схем управления очередями в маршрутизаторах различных производителей достаточно велико. В этом отношении явным лидером являются маршрутизаторы компании Cisco [12]. Данная компания предлагает сетевым администраторам схемы приоритетного обслуживания, а также более изощренные механизмы: взвешенные справедливые очереди (WFQ), настраиваемые очереди, очереди на основе классов приложений и очереди на основе потоков [4]. Под приоритезацией трафика подразумевается включение в состав пакетов специальной информации для их непоследовательной обработки. Приоритезация может использоваться только в сетях, в которых маршрутизаторы или коммутаторы способны различать различные категории трафика.
Если отмечать доминирующие методы управления очередями в современных маршрутизаторах, то алгоритм "первым пришел - первым ушел" (FIFO) является, вероятно, до сих пор самым простым и применяемым для обработки очередей. FIFO относится к так называемым неравноправным схемам обслуживания очередей, поскольку при ее использовании одни потоки могут доминировать над другими, получая несправедливо большую долю полосы пропускания. В связи с этим были предложены равноправные схемы, предусматривающие выделение каждому потоку своего отдельного буфера и равномерное распределение полосы пропускания. Здесь следуем упомянуть фирменный механизм компании Cisco - схему взвешенной справедливой очереди (Weighted Fair Queuing, WFQ). Это адаптивная схема, которая основана на выделении потокам некоторой доли ресурсов, пропорциональной заданному для каждого типа трафика весовому коэффициенту. Определив соответствующие коэффициенты, можно обеспечить, например, чтобы интерактивный трафик, скажем телефонный, обрабатывался с меньшими задержками, чем трафик другого типа. Алгоритм присвоения весовых коэффициентов зависит от конкретной реализации и может учитывать значения битов IP Precedence, IP-адреса, идентификаторы сеансов и т. д. Очереди в модели WFQ могут быть связаны с механизмом профилирования, "сглаживающим" исходящий поток, который работает по принципу воронки (token bucket). Такой механизм используется в основном для трафика данных, поскольку именно он, как правило, имеет "бурстный" характер.
Еще одна популярная схема обслуживания, реализованная в маршрутизаторах, ориентируется на задание классов обслуживания - (Class-Based Queuing, CBQ). Согласно этой схеме каждая очередь ассоциируется с характеристиками конкретного класса, например РНВ в архитектуре Diff-Serv. Требования к очередям определяются набором таких параметров, как минимальная скорость передачи, задержка, допустимая доля потерянных пакетов и т. д. В этом случае, планировщик очередей каждого класса может быть реализован на основе различных алгоритмов, например FIFO, PQ или WFQ.
Организация очереди "в поток" (per-flow queuing) - это семейство механизмов управления, которые обеспечивает обратную связь (feedback), основанную на индивидуальном состоянии потока [39]. Большинство этих алгоритмов используют сложную логику управления и требуют тонкой настройки своих параметров. Собственно из проблемы организации очередей можно выделить задачу управления буфером при его переполнении. В дальнейшем нами будет предложен специальный оригинальный алгоритм из класса алгоритмов управления буфером, базирующийся на отслеживании длины очереди с учетом двух принципиальных метрик для IP-телефонии: задержке и потере пакетов.
До последнего времени единственным механизмом управления очередями в маршрутизаторах был алгоритм сброса хвоста очереди при переполнении FIFO-буфера - drop tail (DT). Следует отметить, что и на сегодняшний день DT остается наиболее популярным механизмом в ІР-маршрутизаторах. Это связано с тем, что его достаточно просто реализовать. Кроме того, этот алгоритм, несмотря на свою простоту, имеет здравую логику. Тем не менее, механизм DT, например, может приводить к несправедливой обработке индивидуальных потоков и может также нарушать синхронизацию потока. Как известно, протокол TCP использует понятие "окна", т.е. количества неподтвержденных отправленных пакетов. Согласно базовой процедуре "медленного старта" [111], принятой в протоколе, значение окна увеличивается экспоненциально от единицы до порогового значения. При перегрузках значение окна вновь сбрасывается до единицы - тем самым уменьшается интенсивность передачи TCP-пакетов. Таким образом, TCP адаптивно предотвращает перегрузку. Отбрасывание пакетов является сигналом о перегрузке и приводит к запуску процедуры медленного старта. Поэтому алгоритм отбрасывания хвоста, когда теряются пакета множества TCP-соединений, вызывает для них синхронное снижение/увеличение интенсивности трафика, что приводит к нежелательному эффекту резкого волнообразного изменения длины очереди, так называемому эффекту глобальной синхронизации. Это явление иллюстрирует Рис. 13. На этом рисунке временные отметки tk на оси аргументов периодической функции q(t) указывают на момент отбрасывания хвоста очереди. DT, как любой ранний best-effort алгоритм, никак не выделяет ни web-потоки, ни интерактивные мультимедийные потоки, которые являются зависимыми от задержек на передаче. Таким образом, с точки зрения управления трафиком DT заставляет сетевых администраторов делать выбор между высокой утилизацией канала (заказывать большие буферы) и низким значением задержки, для уменьшения значения которой необходимы буферы маленького размера.
Построение программного имитационного стенда ІР-телефонии и проведение моделирования трафика мультисервисной сети
Программный комплекс имитационного моделирования позволяет также изучить утилизацию канала, которая формируется разными типами трафика (Рис.26). Сценарий 2. Данный сценарий предлагается для изучения влияния TCP-нагрузки на метрики КО VoIP. Мы использовали две схемы увеличения нагрузки: равномерную (инкрементное изменение по всем типам трафика), а также только для ТСР-трафика с зафиксированным значением количества источников VoIP. В первом случае были выбраны следующие параметры имитационной модели:
Полученные результаты (Табл.11.) характеризуют особенность работы RED-маршрутизатора, когда при переходе в фазу перегрузки время задержки принципиально не увеличивается, т.к. алгоритм превентивного сброса пакетов не дает расти длине очереди. В свою очередь, процент сброса пактов резко возрастает из-за агрессивной политики сбросов пакетов у RED-механизма при приближении к верхнему порогу средней длины очереди. Аналогичная картина наблюдается и при замене в этой модели алгоритма маршрутизации с RED на rtRED. В серии проведенных опытов мы оставляли фиксированным значение источников VoIP - оно равно 10. Несмотря на высокую утилизацию канала все показатели КО для голосового трафика попадают в зону "хорошего" качества во введенном нами выше пространстве метрик (Табл.9). Этот момент обусловлен неявной приоритезацией
Построенная модель трафика мультисервисной сети требует оценки ее адекватности реальному поведению сетевых потоков данных. Для решения подобных задач обычно используются различные статистические и экспертные методики [21]. Имитационная модель в общем случае является просто преобразователем входных переменных в выходные. Поэтому, один из наиболее очевидных подходов к проверке точности модели состоит в сравнении выходов модели и реальной системы при одинаковых (если это возможно) входах. Используя соответствующий критерий для двух выборок, мы можем проверить статистические гипотезы о том, что выборки выходов системы и модели являются выборками из различных совокупностей или что они "практически" принадлежат одной совокупности. Отдельной проблемой является получение экспериментальных данных. В целом, процесс оценки адекватности имитационной модели для трафика ІР-телефонии можно разложить в следующую последовательность шагов. 1. Определение метрик для измерения характеристик трафика (таких, как односторонняя задержка). 2. Разработка методики измерения экспериментальных данных и построение натурных макетов для получения выборок метрик трафика ІР-телефонии. 3. Выбор статистического критерия для сравнения имитационных и натурных выборок. 4. Проведение имитационных и натурных экспериментов, получение и сравнение выборок. При выборе критерия оценки модели трафика ІР-телефонии предлагается использовать критерий Вилкоксона [8]. Действительно, если мерой эффективности работы системы и модели служит одна переменная, то мы имеем дело с одномерной двухвыборочной задачей. Для решения этой задачи применимы различные критерии проверки: 1. Критерий t (критерий Стьюдента) для выборок, распределенных по нормальному закону. 2. Критерий Фишера для выборок, распределенных по нормальному закону. 3. Непараметрические критерии Вилкоксона, Колмогорова-Смирнова и Манны-Уитни для выборок, распределенных по неизвестному закону. 4. Критерий "хи-квадрат", критерий Колмогорова-Смирнова и критерий Крамера - фон Мизеса для проверки гипотезы о том, что исследуемая выборка распределена по тому или иному закону.
Для нашей модели удобно использовать критерий Вилкоксона, т.к. мы предварительно не имеем данных о законах распределения исследуемых величин (задержка, джиттер и процент потерянных пакетов). Данный критерий является достаточно мощной и одновременно простой методикой с хорошей точностью. Также дополнительно мы попытаемся использовать один из критериев, перечисленных в пункте 4, для проверки гипотезы нормального распределения полученных величин метрик КО. Эффективность критерия Вилкоксона относительно критерия t в случае нормального распределения близка к 95%. Этот критерий применим к проверке так называемой гипотезы Н0 о том, что две независимые выборки принадлежат к одной совокупности. Кратко опишем критерий Вилкоксона.
Пусть имеются две выборки размеров m и п, где m п. Упорядочим выборочные значения обоих выборок в одну последовательность длины N = m + п, т.е. составим вариационный ряд. Припишем наименьшему наблюдению в этой упорядоченной последовательности ранг 1, а следующим - ранги в возрастающем порядке. Пусть R - сумма рангов, приписанных наблюдениям из выборки размера гл. Образуем статистику Вилкоксона:
В первых двух случаях говорят о применение одностороннего критерия проверки, а в последнем случае - о двустороннем критерии. Естественно, нам необходимо, чтобы результаты натурного и имитационного моделирования не отличались, т.е. мы будем применять двусторонний критерий. Можно считать, что гипотеза Н0 выполняется, если: w(Q;m;n) W W{Q;m;ri) (51) т.е. если рассчитанная статистика W попадает в интервал между нижним и верхним критическим значениями. Данные значения для выборок, объем которых не превышает 25, берутся из специально составленных таблиц [3]. Если же объем выборки превышает 25, то значения нижнего и верхнего критического значения рассчитываются по ниже приведенным формулам. Все расчеты проводятся для заданного уровня значимости Q. Уровень значимости характеризует строгость проверки гипотезы - чем больше уровень значимости, тем жестче она проверяется. Так, например, гипотеза, принятая для уровня значимости 0,01, может быть отклонена для уровня 0,05. Наиболее полные таблицы (для m=n=25) приведены в [3] с максимальным уровнем значимости 0,10. В таблицах уровни значимости принимают значения 0,52, но максимальный объем выборок данных таблиц ограничен 10. Поэтому с учетом того, что в большинстве статистических задач (например, экономических) Q берется равным 0,05 и большей полноты таблиц [3], установим уровень значимости Q = 0,10. Если хотя бы один из объемов выборок тип превосходит 25, то для вычисления критических значений пользуются следующими формулами:
Величина ф = Ф(1-0) - значения обратной функции нормального распределения с параметрами (0,1), приведенные в таблице [3]. Следует отметить, что формула (52) дает более точные значения, чем (53). Например, для т=5, п=25 и Q=0,025 получаем нижнее критическое значение по формуле (53) равным 41,7, а по формуле (52) равным 42,08. При этом табличное значение равно 42. Аппроксимации (53) и (54) действуют удовлетворительно при всех nam ), если только нет совпадений значений между выборками (хотя в случае непрерывных распределений совпадения могут возникать в принципе лишь с нулевой вероятностью, однако практически они наблюдаются довольно часто и являются следствием неизбежных ошибок округления). При наличии совпадения рекомендуется всем совпавшим величинам приписывать одинаковый ранг, равный арифметическому среднему тех рангов, которые имели бы эти величины до совпадения. Подчеркнем еще раз, что совпадения следует учитывать лишь тогда, когда совпавшие величины принадлежат разным выборкам. Совпадения, целиком состоящие из элементов какой-либо одной выборки, на величину статистики W не влияют.
Разработка и анализ системы управления ІР-телефонией
Подсистема мониторинга трафика включает в себя диспетчер наблюдения в реальном времени за выделенными каналами сети с графическим отображением утилизации каналов. Данная компонента реализована на базе программы MRTG, свободно распространяемой под GNU-лицензией. Для ІР-телефонии диспетчер не только показывает текущий поток голосового трафика, но и количество вызовов, т.е. ведущихся в данный момент разговоров. Кроме этого подсистема мониторинга имеет накопительную базу ежедневной статистики по всем IP-адресам сети, которая доступна в удаленном режиме через стандартный web-броузер. Статистика сгруппирована на зоны по каждому маршрутизатору или прокси-серверу корпоративной сети, что позволяет подробно анализировать как операторскую, так и корпоративную статистику, в том числе и по ІР-телефонии. В таблицах 14 и 15 представлены два типа отчетов. Первый из них предоставляет хит-парад активных по трафику через внешний маршрутизатор ІР-адресов ОКС ВНИИТФ. Второй отчет показывает статистику обращений к внешним адресам для конкретного пользователя сети.
Подобные статистики позволяют не только выявлять узкие места в сети, но и отслеживать динамику изменения нагрузки для конкретных потребителей сетевого трафика.
Компонента учета пользователей обеспечивает ведение единой подробной базы, связанной с работой в сети как коммерческих пользователей, так и сотрудников ФГУП РФЯЦ-ВНИИТФ. Для пользователей ІР-телефонии компонента учета позволяет формировать отчеты, связанные с их телефонными звонками. Табл. 16 иллюстрирует подобную детализацию.
Формат простого отчета пользователя VoIP Нотация вызываемого телефонного номера использует рекомендации ITU [58]. В данной справке также калькулируется разница в стоимости осуществленных телефонных междугородних звонков между местным телефонным оператором связи и собственно ФГУП РФЯЦ-ВНИИТФ, что позволяет вычислять экономию от внедренной услуги.
Для коммерческих пользователей дополнительно включается биллинговая компонента, которая использует ту же единую базу осуществленных звонков. Биллинг формирует документы в форматах, запрашиваемых финансовыми и бухгалтерскими службами. Следует отметить, что среди коммерческих пользователей ІР-телефонии большая часть анонимных, т.к. городское население предпочитает карточную предоплатную схему работы с провайдером. Препейд-блок должен являться обязательной частью биллинговой компоненты управления IP-телефонией. В случае карточной схемы доступ к услуге осуществляется по ПИН-коду. Для корпоративных пользователей возможен обход набора ПИН-кода за счет авто-определения их телефонных номеров (АОН). Наше основное требование к построению системы ІР-телефонии на базе УАТС заключается в обязательной передаче от станции в шлюз исходящего номера. Использование АОН позволит упростить управление системой ІР-телефонии и поможет выполнить требования безопасности.
Функцию политики безопасности определяет отдельная компонента управления доступом для пользователей сети и корпоративной ІР-телефонии. Эта компонента связана с технической политикой защиты информационных ресурсов в ОКС ВНИИТФ, которая вводит несколько зон видимости компьютерных ресурсов предприятия и, наоборот, несколько политик доступа к внешним ресурсам. Несмотря на открытость информации, циркулирующей в ОКС ВНИИТФ, особенность оборонного объекта предполагает большую вероятность попадания в корпоративную зону видимости чувствительной информации [10]. Политика безопасности и
Если рассматривать систему управления только IP-телефонией, то из представленных выше принципов мы видим, что на каждого корпоративного сотрудника заводится учетная запись с прописанным ему списком доступа, в то время как для операторских пользователей подобный фильтр отсутствует.
Имитационный комплекс моделирования топологий, алгоритмов управления и сетевой нагрузки является компонентой, необходимой сетевому администратору большой корпоративной сети, особенно, если через каналы этой сети проходит коммерческий операторский трафик. Только с помощью проведения моделирования поведения трафика можно разделить и оптимизировать корпоративные и операторские потоки данных, в том числе и потоки, формируемые сервисом IP-телефонии.
Структура и функции программного обеспечения имитационного комплекса были подробно описаны в предыдущей главе. На Рис.33 приведен скриншот главного меню системы имитационного моделирования. Набор перечисленных выше программных средств управления сетью является достаточным инструментарием для проектирования и эксплуатации мультисервисной корпоративной/операторской сети, а принцип профилирования пользователей на две зоны обеспечивает различные дисциплины их обслуживания.
Таблица иллюстрирует не просто рост объемов ІР-телефонии, но и качественное изменение структуры трафика ОКС ВНИИТФ. Если сравнить первые две строки таблицы, то мы видим, что доля VoIP-трафика в общем потоке приходящих от провайдера данных увеличилась с менее 1% до почти 6%. Другой характерный момент статистики заключается в уменьшении величины отношения объема трафика VoIP к длительности телефонных разговоров. Этот результат достигнут переводом основного контингента клиентов с шлюза с G.711 кодеком на шлюз с G.729 кодеком, который обеспечивает лучшее сжатие речи.
Проведем более детальный анализ месячной статистики ІР-телефонии за июнь 2004г. При делении пользователей на две группы: корпоративную (сотрудники ФГУП РФЯЦ-ВНИИТФ) и операторскую, в последней также проведем профилирование. Будем рассматривать пользователей, принадлежащих городским организациям и пользователей, которые являются физическими лицами. Наша задача состоит в выделении статистических различий или совпадений между этими группами. Среди общих метрик наибольший интерес для нас будут представлять три:
Простое сравнение статистических данных показывает явную закономерность в увеличении продолжительности телефонного разговора при переходе от организаций к частным лицам и одновременное расширение географии телефонных звонков. Второй момент достаточно очевиден, т.к. корпоративные пользователи принадлежат к оборонному ядерному предприятию с ограниченными возможностями на телефонные контакты с представителями зарубежных организаций. Невысокая длительность в среднем одного телефонного разговора ВНИИТФ объясняется экономическими моментами - каждому структурному подразделению ВНИИТФ обычно выделяются ограничительные квоты на ведение междугородних телефонных разговоров.
Более интересную статистику предоставляет Рис.35, который иллюстрирует временное распределение интенсивности телефонных вызовов. Вполне очевидна форма графика "верблюжий горб" с часовым провалом в обеденное время для распределения производственных звонков. Поведение данного графика соответствует характеристики напряженности рабочего времени предприятия и его значения близки к нулю вне рабочего времени. И наоборот, максимальная интенсивность телефонных вызовов частных лиц приходится на нерабочее вечернее время. График также имеет пик в обеденное время, когда многие сотрудники ВНИИТФ находятся дома.
