Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

УЗБЕКСКОЕ АГЕНТСТВО СВЯЗИ И ИНФОРМАТИЗАЦИИ

ТАШКЕНТСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

«Анализ влияния параметров протокола RSVP на показатели качества обслуживания»

Выпускник Рахимов Ш. Р.

Руководитель Тарасенко Е. В.

ТАШКЕНТ - 2012 г.

Данная выпускная квалификационная работа посвящена обеспечению качества обслуживания в пакетных сетях. Исследовалось влияние параметров протокола резервирования ресурсов RSVP (Resource Reservation Protocol) на показатели качества обслуживания в пакетных сетях. Основной целью данной работы был анализ поведения сетевых характеристик при изменении параметров протокола RSVP. Также рассмотрены вопросы техники безопасности и охрана труда.

Ушбу битирув малакавий иш пакет тармо?лари сифатни таъминлашга ба?ишланган. Асосан RSVP (Resource Reservation Protocol) ресурслари за?иралаш протоколлари параметрларининг пакет тармо?ларидаги хизмати сифатига бўлган таъсири батафсил ўрганиб чи?илган. Ишнинг асосий ма?сади эса RSVP протоколи параметрларини ўзгартирилган ?олатда тармо? хусусиятларини ўзгаришини та?лил ?илишдир.

The final qualification report is related to the provision quality of service in packet-switched networks. Influence of RSVP parameters on the packet-switched network's quality indexes was researched. Mail purpose in this work is analysis status of network characteristics by variation RSVP parameters. As well it was safety measures and labor protection issues had been described.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. МЕХАНИЗМЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ОБСЛУЖИВАНИЯ В ПАКЕТНЫХ СЕТЯХ

1.1 Проблемы обеспечения качества обслуживания в пакетных сетях

1.2 Параметры качества обслуживания

1.3 Механизмы обеспечения качества обслуживания

Выводы

2. ИССЛЕДОВАНИЕ ПРИНЦИПОВ ФУНКЦИОНИРОВАНИЯ ПРОТОКОЛА RSVP

2.1 Общие принципы функционирования протокола RSVP

2.2 Стили резервирования

2.3 Описание параметров протокола RSVP

Выводы

3. ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ ФУНКЦИОНИРОВАНИЯ ПАКЕТНОЙ СЕТИ ПРИ ИСПОЛЬЗОВАНИИ ПРОТОКОЛА RSVP

3.1 Описание имитационной модели

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

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

Выводы

4. ОХРАНА ТРУДА И ТЕХНИКА БЕЗОПАСНОСТИ

4.1 Рациональная организация рабочего места

4.2 Защита людей от поражения электрическим током при работе на оборудовании и электрооборудовании

Выводы

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ВВЕДЕНИЕ

Одним из направлений социально-экономического развития Узбекистана является продвижение к информационному обществу. Такой подход позволит Узбекистану интегрироваться в мировое экономическое пространство как равноправный партнер.

Президент Узбекистана 21 марта 2012 года подписал постановление «О мерах по дальнейшему внедрению и развитию современных информационно-коммуникационных технологий». Данным постановлением были определены основные направления развития ИКТ в Узбекистане. Для осуществления некоторых из них обязательным фактором является развитие технологий предоставления требуемого качества обслуживания, QoS (Quality of Service) [1]. Среди указанных направлений можно выделить следующие:

- развитие инфраструктуры сети и коммуникаций по обеспечению электронной оплаты населением коммунальных услуг и других платежей;

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

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

Для успешного осуществления вышеперечисленных задач по развитию ИКТ в Республике Узбекистан необходимо обеспечить для данных направлений требуемое качество обслуживания, чтобы при любой нагрузке сети интерактивные услуги были доступны всем заинтересованным лицам.

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

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

Единственной услугой, поддерживаемой в сети интернет, является негарантированная доставка данных (best-effort service). Поэтому для решения проблемы обеспечения качества обслуживания были разработаны уровни обеспечения качества обслуживания сети: дифференцированное и гарантированное обслуживание (differentiated service, guaranteed service) [2].

Дальнейшее развитие ИКТ в Узбекистане невозможно представить без уже начатой миграции к сетям следующего поколения (Next Generation Network, NGN), которое требует реализации различных уровней качества обслуживания сети.

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

1. МЕХАНИЗМЫ ОБЕСПЕЧЕНИЯ КАЧЕСТВА ОБСЛУЖИВАНИЯ В ПАКЕТНЫХ СЕТЯХ

1.1 Проблема обеспечения качества обслуживания в пакетных сетях

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

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

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

В современных сетях передачи данных (СПД) преимущественно используется коммутация пакетов. Сети с пакетной коммутацией не обладают вышеперечисленными недостатками.

Например, паузы в телефонном разговоре могут составлять до 40 % общего времени соединения. Пакетная коммутация позволяет «вырезать» паузы и использовать высвободившуюся пропускную способность канала для передачи трафика других абонентов, либо трафика других приложений [3].

Качество доставки в традиционных сетях IP базируется на принципе «наилучшей попытки» (best effort). Концепция «наилучшей попытки» предполагает, что пользователи справедливо разделяют доступные сетевые ресурсы, трафик передается со скоростью, максимально возможной в данных условиях загрузки ресурсов сети, но при этом не гарантируется обеспечение любого предварительно определенного уровня качества обслуживания. Best-effort service не является уровнем обеспечения качества обслуживания (Quality of Service, QoS).

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

Подобный тип передачи пакетов вполне приемлем для приложений, не чувствительных к временным задержкам [4], таких как передача или получение электронной почты, просмотр интернет-страниц, загрузка данных с FTP-сервера и т.п.

С учетом переизбытка сетевых ресурсов в транспортных сетях, построенных на базе волоконно-оптических линий связи, принцип best-effort в определенной степени позволяет обеспечить сегодня требования телефонии (голос поверх IP, Voice over IP) и других приложений реального времени.

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

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

Методы обеспечения качества обслуживания гарантируют устойчивую работу современных мультимедийных приложений, уменьшают неопределенность временной задержки передачи пакетов до получателя и направлены на улучшение характеристик производительности и надежности сети [6].

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

1.2 Параметры качества обслуживания

Речевая информация и, отчасти, видеоинформация являются примерами трафика, чувствительного к задержкам. Когда задержка доставки пакета превышает определенные критические значения, такие пакеты отбрасываются. В приложениях реального времени (например, в IP-телефонии) это ведет к ухудшению качества речи. Ограничения, связанные со средней задержкой пакетов IP, играют ключевую роль для успешного внедрения технологии Voice over IP (VoIP), видео-конференций и других приложений реального времени.

Для большинства случаев качество связи определяется четырьмя параметрами:

- полоса пропускания (Bandwidth), описывает номинальную пропускную способность среды передачи информации, определяет ширину канала. Измеряется в bit/s (bps), kbit/s (Kbps), Mbit/s (Mbps), Gbit/s (Gbps);

- задержка при передаче пакета (Delay), измеряется в миллисекундах (ms);

- колебания (дрожание) задержки при передаче пакетов - джиттер;

- потеря пакетов (Packet loss). Определяет количество пакетов, потерянных в сети во время передачи.

Измерение указанных параметров производится на определенном интервале времени. Чем меньше этот временной интервал, тем более жесткие требования предъявляются к сети и ко всем ее элементам, поскольку обеспечение QoS «из конца в конец» (end-to-end) требует взаимодействия всех узлов на пути трафика и определяется надежностью, функциональностью и производительностью самого «слабого» элемента сети.

Рекомендация МСЭ-Т Y.1540 определяет следующие параметры, характеризующие доставку IP-пакетов [7]:

Задержка доставки пакета IP (IP packet transfer delay, IPTD). Параметр IPTD определяется как время (t₂ - t₁) между вводом пакета во входную точку сети в момент t₁ и выводом пакета из выходной точки сети в момент t₂, где

(t₂ > t₁) и (t₂ - t₁) <= T_mах.

Параметр IPTD определяется как время доставки пакета между источником и получателем для всех пакетов - как успешно переданных, так и пораженных ошибками.

Средняя задержка доставки пакета IP - параметр, специфицированный в [8], определяется как средняя арифметическая величина задержек пакетов в выбранном наборе переданных и принятых пакетов. Значение средней задержки зависит от передаваемого в сети трафика и доступных сетевых ресурсов, в частности, от пропускной способности. Рост нагрузки и уменьшение доступных сетевых ресурсов ведут к росту очередей в узлах сети и, как следствие, к увеличению средних задержек доставки пакетов.

Вариация задержки пакета IP (IP packet delay variation, IPDV). Параметр V_k, характеризует вариацию задержки IPDV. Для IP-пакета с индексом k этот параметр определяется между входной и выходной точками сети в виде разности между абсолютной величиной задержки X_k при доставке пакета с индексом k, и определенной эталонной (или опорной) величиной задержки доставки пакета IP, d_l,2, для тех же сетевых точек:

V_k = X_k - d_1,2

Эталонная задержка доставки пакета IP, d_1,2, между источником и получателем определяется как абсолютное значение задержки доставки первого пакета IP между данными сетевыми точками. Вариация задержки пакета IP, или джиттер, проявляется в том, что последовательные пакеты прибывают к получателю в нерегулярные моменты времени. В системах IP-телефонии это ведет к искажениям звука и результате речь становится неразборчивой.

Коэффициент потери пакетов IP (IP packet loss ratio, IPLR). Коэффициент IPLR определяется как отношение суммарного числа потерянных пакетов к общему числу принятых в выбранном наборе переданных и принятых пакетов. Потери пакетов в сетях IP возникают в том случае, когда значение задержек при их передаче превышает нормированное значение, определенное выше как Т_mах. Если пакеты теряются, то при передаче данных возможна их повторная передача по запросу принимающей стороны. В системах VoIP пакеты, пришедшие к получателю с задержкой, превышающей Т_mах, отбрасываются, что ведет к провалам в принимаемой речи. Среди причин, вызывающих потери пакетов, необходимо отметить рост очередей в узлах сети, возникающих при перегрузках.

Коэффициент ошибок пакетов IP (IP packet error ratio, IPER). Коэффициент IPER определяется как суммарное число пакетов, принятых с ошибками, к сумме успешно принятых и пакетов, принятых с ошибками.

Mean Opinion Score (MOS) - средняя экспертная оценка разборчивости речи. Метод субъективного тестирования качества речи, часто используемый для сравнения характеристик речевых кодеков, при котором слушатели выставляют оценки по пятибалльной системе. Результирующая оценка MOS вычисляется как среднее арифметическое для большого числа оценок.

1.3 Механизмы обеспечения качества обслуживания

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

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

Одним из основных понятий в концепции обеспечения требуемого уровня качества обслуживания в современных сетях является соглашение об уровне обслуживания (Service Level Agreement, SLA) [7]. Первые SLA-контракты были разработаны в середине 90-х годов при предоставлении услуг передачи данных с использованием технологий Frame Relay, ATM и IP. Необходимость подобных контрактов была вызвана возрастающими требованиями к операторам со стороны клиентов, чей бизнес все больше зависел от надежной и своевременной передачи информации. SLA предполагает повышенную ответственность поставщика услуг. SLA, называемое в ряде источников контрактом по трафику, представляет собой контракт между пользователем и провайдером услуг/сетевым провайдером. В SLA определяются основные характеристики (профиль) трафика, формируемого в оборудовании пользователя, и параметры QoS, предоставляемые провайдером. SLA может включать в себя также и ценовые характеристики. Техническая часть SLA специфицирует набор параметров и их значения, которые вместе определяют уровень обслуживания, обеспечиваемый трафику пользователя со стороны сетевого провайдера.

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

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

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

Priority Queuing (PQ) обеспечивает безусловный приоритет одних пакетов над другими. Механизм приоритетной обработки трафика основан на разделении всего сетевого трафика на небольшое количество классов, а затем назначении каждому классу некоторого числового признака - приоритета.

Custom Queuing (CQ) обеспечивает настраиваемые очереди. Предусматривается управление долей полосы пропускания канала для каждой очереди.

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

Взвешенное справедливое обслуживание (Weighted Fair Queing, WFQ) - это комбинированный механизм, сочетающий приоритетное обслуживание очередей с взвешенным. Существуют различные реализации WFQ, которые отличаются способом назначения весов и поддержкой различных режимов работы. Наиболее распространенная схема предусматривает существование одной особой очереди, которая обслуживается по приоритетной схеме, то есть первой и до тех пор, пока все заявки из нее не будут выбраны. Остальные очереди маршрутизатор просматривает последовательно, по алгоритму взвешенного обслуживания. WFQ автоматически справедливо распределяет доступную пропускную способность, дополнительно учитывая ToS (Type of Service). Байт типа обслуживания (Type of Service, ToS) используется для указания абстрактных параметров требуемого качества обслуживания. На основании этих параметров производится выбор реальных характеристик механизмов обслуживания при передаче датаграммы через заданную сеть [9].

Потоки с одинаковыми IP-приоритетами ToS получат равные доли полосы пропускания; потоки с большим IP-приоритетом - большую долю полосы. В случае перегрузок ненагруженные высокоприоритетные потоки функционируют без изменений, а низкоприоритетные высоконагруженные - ограничиваются. Протокол RSVP работает вместе с WFQ.

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

Class Based Weighted Fair Queuing (CBWFQ) соответствует механизму обслуживания очередей на основе классов. Весь трафик разбивается на 64 класса на основании следующих параметров: входной интерфейс, лист доступа (access list), протокол, значение DSCP [10], метка MPLS QoS. Общая пропускная способность выходного интерфейса распределяется по классам.

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

Integrated Service (IntServ, [11]) - модель интегрированного обслуживания, предназначенная для обеспечения сквозного (End-to-End) качество обслуживания, гарантируя необходимую пропускную способность. IntServ использует для своих целей протокол сигнализации RSVP, позволяет приложениям выражать сквозные требования к ресурсам и содержит механизмы обеспечения данных требований. IntServ можно кратко охарактеризовать как резервирование ресурсов (Resource reservation). Механизм обеспечения качества обслуживания с использованием протокола RSVP подробно рассмотрен в следующей главе.

Differentiated Service (DiffServ, [12]) предоставляет возможность согласованной обработки различных классов трафика. Модель DiffServ обеспечивает дифференцирование трафика путем его разбивки на классы с различным приоритетом. В соответствии с этой моделью, разработанной группой IETF DiffServ, байт ToS получил название байта DS, а шесть его битов отведены пол код DiffServ [13]. Каждому значению этого кода соответствует свой класс пересылки РНВ (Per-Hop Behavior Forwarding Class), определяющий ожидаемый уровень обслуживания. В рамках каждого класса пакеты должны обрабатываться в соответствии определенными для него требованиями к качеству обслуживания. Трафик будет разделяться на ограниченное число классов или «групп поведения» (behavior), что обеспечит возможность масштабируемой дифференциации услуг.

РНВ-политика - политика пошагового обслуживания, определяет поведение сетевого узла в отношении пакетов с определенным значением поля кода дифференцированной услуги (Differentiated Services Code Point, DSCP) [10]. Все пакеты потока трафика со специфическим требованием к обслуживанию несут в себе одно и то же значение поля DSCP.

Модель DiffServ описывает архитектуру сети как совокупность пограничных участков и ядра сети [14]. Поступающий в сеть трафик классифицируется и нормируется пограничными маршрутизаторами. Нормирование трафика предусматривает измерение его параметров, проверку соответствия заданным правилам предоставления услуг, профилирование (при этом пакеты, не укладывающиеся в рамки установленных правил, могут быть отсеяны) и другие операции. В ядре сети магистральные маршрутизаторы или коммутаторы пересылают трафик в соответствии с классом РНВ, код которого указан в поле DS.

Достоинства модели DiffServ состоят в том, что она обеспечивает единое понимание того, как должен обрабатываться трафик определенного класса и позволяет разделить весь трафик на относительно небольшое число классов, вместо того чтобы отдельно анализировать каждый поток.

К настоящему времени определены два класса трафика в рамках DiffServ:

- срочная доставка (Expedited Forwarding PHB Group);

- гарантированная доставка (Assured Forwarding PHB Group).

Механизм обеспечения QoS на уровне сетевого устройства, применяемый в DiffServ, включает в себя четыре операции:

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

- маркировка пакетов в соответствии с произведенной классификацией и данными битов Diff-Serv;

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

- формирование трафика, состоящего в организации очередей с учетом приоритетов.

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

Выводы

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

- предоставление гарантированной полосы пропускания;

- повышение производительности сетевых устройств - маршрутизаторов, шлюзов;

- использование магистралей с высокими пропускными способностями;

- реализация различных механизмов обеспечения качества обслуживания.

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

3. Функции качества обслуживания в сетях IP заключаются в обеспечении гарантированного и дифференцированного обслуживания сетевого трафика путем передачи контроля за использованием ресурсов и загруженностью сети ее оператору. QoS представляет собой набор требований, предъявляемых к ресурсам сети при транспортировке потока данных. QoS обеспечивает гарантию передачи данных и, основанный на системе правил, контроль за средствами повышения производительности IP-сети, такими, как механизм распределения ресурсов, коммутация, маршрутизация, механизмы обслуживания очередей и механизмы отбрасывания пакетов.

2. ИССЛЕДОВАНИЕ ПРИНЦИПОВ ФУНКЦИОНИРОВАНИЯ ПРОТОКОЛА RSVP

2.1 Общие принципы функционирования протокола RSVP

Проблемная группа проектирования Интернет (Internet Engineering Task Force, IETF) определил RSVP [15] как сигнальный протокол для архитектуры IntServ. Этот протокол позволяет приложениям посылать сообщения в сеть о своих QoS-требованиях для каждого потока. Чтобы определить количественные характеристики этих требований с целью управления доступом, используются служебные параметры.

Протокол RSVP может применяться в любых приложениях, которые для нормального функционирования требуют определенного уровня качества обслуживания в сети. Например, приложения с групповой рассылкой, такие, как приложения аудио- и видеоконференций. Несмотря на то, что изначально протокол RSVP был ориентирован на мультимедийный трафик, с его помощью легко можно резервировать полосу пропускания для однонаправленного трафика, например для трафика протокола сетевой файловой системы (Network File System, NFS) и управляющего трафика виртуальных частных сетей (Virtual Private Network, VPN).

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

Структура и содержимое параметров QoS документировано в спецификации [16]. RSVP периодически посылает сообщения для поддержания необходимого состояния вдоль всего маршрута обмена. При отсутствии этих сообщений происходит тайм-аут и резервирование аннулируется. RSVP имеет следующие атрибуты:

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

- является симплексным протоколом, т.е. выполняет резервирование для однонаправленного потока данных;

- ориентирован на получателя, т.е. получатель данных инициирует и поддерживает резервирование ресурсов для потока;

- поддерживает динамическое членство в группе и автоматически адаптируется к изменениям маршрутов;

- не является маршрутным протоколом, но зависит от существующих и будущих маршрутных протоколов;

- транспортирует и поддерживает параметры управления трафиком и политикой, которые остаются непрозрачными для RSVP;

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

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

- может работать с сетевыми протоколами IPv4 и IPv6.

Конечные системы используют протокол RSVP для запрашивания у сети определенного уровня QoS от имени потока данных приложения. RSVP-запросы передаются по сети при прохождении каждого узла, который используется для передачи потока. Протокол RSVP пытается зарезервировать ресурсы для потока данных на каждом из этих узлов.

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

Рис. 2.1. Потоки данных и управление протокола RSVP

Перед тем как зарезервировать ресурсы, RSVP-демон маршрутизатора соединяется c двумя локальными модулями принятия решения - модулем управления доступом (admission control) и модулем управления политикой (policy control) [17]. Модуль управления доступом определяет, имеет ли узел достаточно свободных ресурсов для обеспечения запрошенного уровня QoS. Модуль управления политикой определяет, есть ли у пользователя администраторские права, для того чтобы произвести резервирование. Если какая-либо из проверок не прошла, RSVP-демон отправляет сообщение об ошибке процессу приложения, которое создало запрос. Если обе проверки прошли нормально, RSVP-демон устанавливает параметры классификатора пакетов (packet classifier) и планировщика пакетов (packet scheduler) для получения нужного уровня QoS. Классификатор пакетов определяет класс QoS для каждого пакета, а планировщик пакетов управляет передачей пакетов, основываясь на их классе QoS. Взвешенный алгоритм равномерного обслуживания очередей (Weighted Fair Queuing, WFQ) и взвешенный алгоритм произвольного раннего обнаружения (Weighted Random Early Detection, WRED) обеспечивают поддержку QoS на уровне планировщика.

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

Резервирование всегда должно следовать по одному и тому же одноадресному пути или по многоадресному дереву. В случае выхода из строя маршрута маршрутизатор должен сообщить об этом RSVP-демону, чтобы генерируемые им RSVP-сообщения передавались по новому маршруту.

Процесс установки резервирования можно разбить на пять отдельных шагов [18]:

1. Отправители данных посылают управляющие сообщения RSVP PATH по тому же пути, по которому они отправляют обычный трафик с данными. В этих сообщениях описываются данные, которые уже отправляются или только будут отправляться.

2. Каждый RSVP-маршрутизатор перехватывает РАТН-сообщения, сохраняет IP- адрес предыдущей точки назначения, записывает вместо него свой собственный адрес и отправляет обновленное сообщение дальше по тому же пути, по которому передаются данные приложения.

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

4. RSVP-маршрутизаторы определяют, могут ли они удовлетворить эти RESV-запросы. Если нет, они отказывают в резервировании. Если да, то они объединяют полученные запросы на резервирование и отсылают запрос предыдущему маршрутизатору.

5. Отправители, получив запросы на резервирование ресурсов от соответствующих маршрутизаторов, считают резервирование ресурсов состоявшимся. Обратите внимание, что реальное резервирование ресурсов осуществляется RESV-сообщениями.

Механизм RSVP-резервирования схематически показан на рис. 2.2.

Рис. 2.2. Механизм RSVP-резервирования ресурсов

Пакеты, идущие от приложения на машине-источнике к приложению на машине-получателе, формируют отдельный поток. С целью управления доступом требования потока представляются в виде параметров объекта FlowSpec.

RSVP-отправитель (RSVP-sender) - это приложение, инициирующее отправку трафика в RSVP-сеансе. Ниже перечислены спецификации потока, которые RSVP-отправители могут передавать по RSVP-сети:

- средняя скорость передачи данных;

- максимальный размер всплеска [19].

По сети, состоящей из RSVP-совместимых маршрутизаторов (RSVP-enabled router network), прокладывается путь между RSVP-отправителями и RSVP- получателями.

RSVP-получатель (RSVP-receiver) - это приложение, которое получает трафик в RSVP-сеансе. Во время конференций или при передаче голоса по протоколу IP (Voice over IP, VoIP) приложение может играть роль и RSVP-отправителя, и RSVP-получателя. Ниже перечислены спецификации потока, который RSVP-получатели могут передавать по RSVP-сети:

- средняя скорость передачи данных;

- максимальный размер всплеска [19];

- QoS, включая: гарантированное обслуживание - в PATH-сообщениях также описываются максимально возможные задержки в сети; обслуживание с управляемой нагрузкой - маршрутизаторы гарантируют только то, что сетевые задержки будут минимальными.

В протоколе RSVP используются семь типов сообщений: два обязательных - PATH и RESV, и пять опциональных - PATH ERROR, PATH TEARDOWN, RESV ERROR, RESV CONFIRM и RESV TEARDOWN. RSVP-маршрутизаторы и клиенты используют эти сообщения для создания и поддержания состояний резервирования.

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

В общем заголовке имеются следующие поля:

- Vers. (4 бита) - номер версии протокола;

- Flags (4 бита) - 0x01-0x08. Флаги зарезервированы, пока не определены;

- Msg. Type (8 бит) - тип сообщения;

- Checksum (16 бит) - дополнение по модулю один контрольной суммы сообщения (в процессе вычисления поле контрольной суммы считается нулевым). Если в поле записан нуль, это означает, что контрольная сумма не вычислялась;

- Send_TTL (8 бит) - значение TTL для протокола IP, с которым было послано сообщение;

- Length (16 бит) - полная длина RSVP сообщения в байтах, включая общий заголовок и объекты переменной длины, которые за ним следуют.

	0 4	8	16	31
	Vers.	Flags	Msg. Type	Checksum
	Send_TTL	Reserved	Length

Рис. 2.3. Формат общего заголовка

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

Отправители периодически посылают РАТН-сообщения [20]. В описание потока включается IP-адрес источника и приемника, IP-протокол и, при необходимости, порты протокола передачи датаграмм пользователя (User Datagram Protocol, UDP) или порты протокола управления передачей (Transmission Control Protocol, TCP). Отправители проводят оценку ожидаемых затрат ресурсов для передачи данных. При этом определяется средняя скорость передачи и размер всплеска [19].

PATH-сообщения отправляются многоадресным группам или одноадресной точке назначения потока, для которого производится резервирование. RSVP-маршрутизаторы обнаруживают их по признаку IP Router Alert в IP-заголовке или по UDP-сообщению, предназначенному для индивидуального UDP-порта. При получении РАТН-сообщений маршрутизатор создает блок состояния пути (Path State Block, PSВ).

В РАТН-сообщениях содержится периодический hello-интервал, указывающий на частоту посылки этих сообщений отправителем. По умолчанию hello-интервал равен 30 s. Очень важно иметь небольшой hello-интервал или быструю схему повторной передачи, поскольку из-за потери РАТН-сообщения может ухудшиться производительность VoIP-приложений вследствие задержки при установке RSVP-резервирования на пути VoIP-вызова. Блок PSB сбрасывается, если получено сообщение PATH TEARDOWN, вышла из строя линия связи или если блок не обновлялся новым РАТН-сообщением в течение четырех hello-интервалов.

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

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

Получатели периодически отправляют RESV-сообщения [20]. Они описывают потоки и необходимые ресурсные гарантии, используя информацию, полученную из РАТН-сообщений: IP-адреса источника и пункта назначения, IP-протокола и, при необходимости, UDP- или TCP-портов. С помощью спецификации потока они также описывают необходимую битовую скорость и характеристики задержки. RESV-сообщения проходят через все RSVP-маршрутизаторы по маршрутизируемому пути к отправителю, для которого производится резервирование ресурсов. По приходе RESV-сообщений (FlowSpec, FilterSpec) маршрутизаторы создают блоки состояния резервирования (Reservation State Block, RSB).

В RESV-сообщениях содержится периодический hello-интервал, указывающий на частоту посылки этих сообщений получателем. Блок RSB сбрасывается при получении сообщения RESV TEARDOWN, выходе из строя канала или если блок не обновлялся новым RESV-сообщением в течение четырех hello-интервалов.

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

Если RESV-сообщение используется для сквозного резервирования ресурсов и получатель запрашивает подтверждение резервирования, то получателям или маршрутизаторам, расположенным в точках объединения запросов, отправляется сообщение RESV CONFIRM.

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

RSVP использует подход soft state (гибкое состояние) для управления состоянием резервирования в маршрутизаторах и ЭВМ. Гибкое состояние RSVP создается и периодически освежается посредством сообщений Path и Resv. Состояние уничтожается, если не приходит подтверждения в течение заданного времени тайм-аута очистки. Состояние может быть стерто также посредством сообщения teardown (уничтожение). По истечении каждого таймаута обновления и после любых изменений состояния RSVP осуществляет проверку, для того чтобы подготовить и отправить сообщения обновления Path и Resv последующим узлам.

Сообщения Path и Resv практически эквивалентны (idempotent). Когда маршрут меняется, следующее сообщение Path инициализирует состояние прохода для нового маршрута, а последующие сообщения Resv установят для него резервирование. Состояние на неиспользованном в данный момент сегменте маршрута будет аннулировано по таймауту.

Периодическая передача сообщений обновления от ЭВМ и маршрутизаторов позволяет компенсировать случайные потери отдельных RSVP сообщений. Если таймаут удаления установлен равным K периодам обновления, тогда RSVP может допускать потерю K-1 RSVP-пакетов подряд без аннулирования состояния. Механизм управления сетевым трафиком должен быть сконфигурирован так, чтобы предоставить минимальную полосу пропускания для сообщений RSVP, чтобы предотвратить их потерю из-за перегрузки канала.

Сообщениe Teardown (аннулирование) удаляет путь или состояние резервирования. Оно настоятельно рекомендуется, так как ускоряет переходные процессы в сети.

Существует два типа RSVP сообщений аннулирования: PathTear и ResvTear. Сообщение PathTear направляется всем получателям и ликвидирует состояние пути, а также все зависящие от него состояния резервирования. Сообщение ResvTear уничтожает состояние резервирования и направляется всем отправителям.

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

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

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

Существует два типа RSVP сообщений об ошибках: ResvErr и PathErr. Они посылаются отправителю (виновнику ошибки) и не изменяют состояния прохода в узлах, через которые проходят.

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

Запрос резервирования, не прошедший контроль допуска создает состояние блокады в соответствующем узле, но остается действующим во всех предшествующих узлах. Было предложено, чтобы эти резервирования до точки отказа были удалены, но были сохранены по следующим причинам:

- заказываемый ресурс доступен по всей длине пути;

- нужно получить желаемый уровень QoS вдоль оговоренного пути так далеко, как это возможно.

Механизм управления политикой определяет, каким пользователям или приложениям позволено осуществлять резервирование и в каком объеме. RSVP-запросы QoS позволяют определенным пользователям получить предпочтительный доступ к сетевым ресурсам. Для предотвращения злоупотреблений, необходима некоторая обратная связь. Обратная связь может быть реализована с помощью административной политики обеспечения доступа, или путем введения прямой или виртуальной оплаты резервирования. В любом случае требуется идентификация пользователя. На вход управления политикой поступают специфические блоки данных, которые заключены в объектах POLICY_DATA протокола RSVP. Эти блоки могут включать в себя параметры доступа пользователя, его класс, номер аккаунта, пределы квоты и пр.

При использовании протокола RSVP возникают определенные проблемы безопасности:

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

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

- безопасные потоки данных. Использование IPSEC (IP Security) в потоке данных создает проблему для RSVP: если заголовки пакетов транспортного и вышестоящих уровней зашифрованы, общие номера порта RSVP не могут использоваться для определения сессии или отправителя. Для решения этой проблемы определено расширение RSVP, в котором идентификатор секретности (IPSEC SPI) играет ту же роль что и номер порта [20].

Протокол RSVP приспособлен для работы через такие, не поддерживающие его, сетевые области. Как поддерживающие протокол RSVP так и не поддерживающие протокол RSVP маршрутизаторы переадресуют сообщения Path в соответствие с адресом места назначения, используя свои локальные таблицы маршрутизации. Следовательно, на маршрутизацию сообщений Path не оказывает влияние наличие промежуточных маршрутизаторов, лишенных RSVP поддержки. Когда сообщение Path проходит через сетевую область, не поддерживающую RSVP, оно, направляясь к следующему узлу, поддерживающему RSVP, несет в себе IP-адрес последнего маршрутизатора. Сообщение Resv тогда переадресуется непосредственно следующему маршрутизатору на пути к отправителю.

Узлы из области, не поддерживающей протокол RSVP, могут внести искажения в QoS. При встрече области без поддержки RSVP протокол устанавливает бит-флаг NonRSVP и передает его механизму управления трафиком. Управление трафиком комбинирует этот однобитовый флаг со своей собственной информацией об источниках и передает ее вдоль транспортного пути получателям, используя спецификацию Adspecs [16].

2.2 Стили резервирования

RSVP-резервирование ресурсов для потока можно разбить на два главных типа: индивидуальное и общее.

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

Индивидуальное резервирование происходит явно для отправителя и устанавливается с помощью стиля резервирования с фиксированным фильтром (Fixed Filter, FF). Символически запрос на резервирование в стиле FF можно представить как FF(S,Q), где S -- это отправитель, a Q -- объект FlowSpec.

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

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

...