Автор работы: Пользователь скрыл имя, 08 Июня 2014 в 15:22, дипломная работа
Основной целью группового вещания является создание эффективного механизма передачи данных по схеме "один-ко-многим" и "многие-ко-многим". Традиционные механизмы стека TCP/IP доставки пакетов мало пригодны для поддержки группового вещания. Например, использование уникальных адресов (unicast) приводит к необходимости установления многочисленных двухточечных соединений между отправителем и каждым из получателей. Другим способом передачи данных является широковещательная передача, когда станция направляет пакеты, используя широковещательные адреса (broadcast). Пакеты с такими адресами передаются всем конечным узлам указанной сети независимо от того, нужны ли они каждому из них. Во многих ситуациях такой способ передачи также оказывается неэффективным вследствие своей избыточности, которая ведет к чрезмерному росту трафика, особенно в крупных сетях.
Как при взвешенном, так и при приоритетном обслуживании, трафик делится на несколько классов, и для каждого класса ведется отдельная очередь пакетов. Но с каждой очередью связывается не ее приоритет, а процент пропускной способности выходного интерфейса, гарантируемый данному классу трафика при перегрузках этого интерфейса. В примере, приведенном на рис. 4.3, устройство поддерживает 5 очередей для 5 классов трафика. Этим очередям соответствует 10%, 10%, 30%, 20% и 30% пропускной способности выходного интерфейса при перегрузках.
Рис. 4.3. Взвешенные настраиваемые очереди
Достигается поставленная цель тем, что очереди обслуживаются последовательно и циклически, и в каждом цикле обслуживания из каждой очереди выбирается такое число байт, которое соответствует весу данной очереди. Например, если цикл просмотра очередей в рассматриваемом примере равен 1 секунде, а скорость выходного интерфейса равна 100 Мбит/с, то при перегрузках в каждом цикле из первой очереди выбирается 10 Мбит данных, из второй тоже 10 Мбит, из третьей — 30 Мбит, из четвертой — 20 Мбит, а из пятой — 30 Мбит. В результате каждому классу трафика достается гарантированный минимум пропускной способности, что во многих случаях является более желательным результатом, чем подавление низкоприоритетных классов высокоприоритетным.
Оценить уровень задержек сложнее, чем уровень пропускной способности. Для того чтобы он был соизмерим со временами передачи пакетов, цикл работы арбитра очереди должен быть, естественно, меньше, чем 1 секунда — значение, выбранное для иллюстрации метода и упрощения расчетов. При таком времени цикла задержка может составить 1 секунду и больше, так как арбитр возвращается к каждой очереди не чаще, чем раз в секунду, кроме того, в очереди может находиться более одного пакета. Время цикла в 100 мкс более подходит приведенному примеру. С одной стороны, оно обеспечивает обслуживание очереди каждого класса каждые 100 мкс. С другой стороны, этого времени достаточно, чтобы выбрать из каждой очереди в среднем по несколько пакетов (учитывая, что размер пакета в сетях Ethernet колеблется от 64 до 1518 байт).
На уровень задержек и вариации задержек пакетов для некоторого класса трафика при взвешенном обслуживании в значительной степени влияет коэффициент нагрузки трафика данного класса. В этом случае коэффициент подсчитывается как отношение интенсивности входного трафика класса к пропускной способности, выделенной этому классу его весом. Качественное поведение очереди и, соответственно, задержек здесь выглядит примерно так же, как и в случае очереди FIFO — чем меньше коэффициент нагрузки, тем меньше средняя длина очереди и тем меньше задержки.
Точные значения параметров QoS для алгоритма взвешенного обслуживания предсказать трудно. На них оказывают существенное влияние все динамически изменяющиеся параметры нагрузки сетевого устройства — интенсивность пакетов всех классов и вариации промежутков времени между прибытием пакетов. В общем случае, взвешенное обслуживание приводит к большим задержкам и их вариациям, чем приоритетное обслуживание для самого приоритетного класса, даже при значительном превышении выделенной пропускной способности над интенсивностью входного потока данного класса. Но для более низких приоритетных классов это соотношение может оказаться и несправедливым, поэтому для создания более благоприятных условий обслуживания всех классов трафика взвешенное обслуживание часто оказывается более приемлемым.
Как и для приоритетного обслуживания, администратор может назначать разным классам очередей буферы различных размеров. Уменьшение размеров буферов для очередей приведет к увеличению потерь пакетов при перегрузках, но зато уменьшаются времена ожидания для тех пакетов, которые не были отброшены и попали в очередь.
Взвешенное справедливое обслуживание (Weighted Fair Queuing, WFQ) является комбинированным механизмом обслуживания очередей, сочетающим приоритетное обслуживание со взвешенным. Существует большое количество различных реализаций WFQ производителями сетевого оборудования. Эти реализации отличаются способом назначения весов и поддержкой различных режимов работы, поэтому в каждом конкретном случае необходимо знакомиться с деталями конкретного WFQ.
Наиболее распространенная схема предусматривает существование одной особой очереди, которая обслуживается по приоритетной схеме, то есть в первую очередь и до тех пор, пока все заявки из нее не будут выбраны. Эта очередь предназначена для системных сообщений, сообщений управления сетью и, возможно, пакетов наиболее критических и требовательных приложений. Во всяком .случае, предполагается, что ее трафик имеет невысокую интенсивность, так что значительная часть пропускной способности выходного интерфейса остается другим классам трафика.
Остальные очереди маршрутизатор просматривает последовательно, по алгоритму взвешенного обслуживания (рис. 4.4). Администратор может задать вес каждого класса трафика, то есть количество байт из каждой очереди, выбираемых перед переходом к следующей. Возможен и вариант работы по умолчанию, когда всем остальным классам трафика достается равное количество пропускной способности выходного интерфейса, оставшейся от трафика приоритетного класса.
Производители оборудования дополняют механизм WFQ некоторыми полезными режимами работы. Например, в маршрутизаторах компании Cisco существует несколько разновидностей WFQ:
Для основанного на потоках варианта FWFQ в маршрутизаторе создается столько очередей, сколько потоков существует в трафике. При применении алгоритма FWFQ под потоком понимаются пакеты, имеющие определенные значения IP-адресов назначения и источника и/или портов TCP/UDP источника и назначения (типа протоколов транспортного уровня), значения поля TOS. То есть поток — это последовательность пакетов от одного приложения с определенными параметрами качества обслуживания, заданными в поле TOS. (Иногда такой поток называют микропотоком — microflow, оставляя термин "поток" для агрегированных микропотоков, представляющих, например, совокупность всех микропотоков от приложений одного пользователя или определенной подсети.)
Каждому потоку соответствует отдельная выходная очередь. Во время периодов перегрузок механизм WFQ назначает каждой выходной очереди равные значения пропускной способности порта. Поэтому иногда алгоритм FWFQ называют просто FQ (Fair Queuing) — справедливое обслуживание.
Основанный на классах вариант CWFQ в маршрутизаторах Cisco имеет два подварианта:
Для варианта QoS-rpynn администратор задает веса пропускной способности, выделяемой каждой QoS-rpynne, а также (опционально) максимальную длину очереди.
Для очередей, основанных на классах QoS, пакеты, которые не назначены ни в одну группу, принадлежат к группе 0. При назначении весов WFQ нужно принимать во внимание следующее:
Рис. 4.4. - Взвешенное справедливое обслуживание
Для варианта, использующего для классификации значение TOS, существуют веса классов по умолчанию. Они назначаются, если администратор явно не задал их с помощью команды weight. Для классификации используется 2 младших бита трехразрядного подполя IP Precedence из поля TOS, так что в этом варианте существует всего 4 класса трафика. По умолчанию, классу О выделяется 10% выходной пропускной способности, классу 1—20%, классу 2—30% и классу 3—40%. Чем выше класс, тем выше значимость трафика, поэтому выделение ему по умолчанию большей доли пропускной способности создает для него более привилегированные условия продвижения.
Случайное раннее обнаружение — RED
Техника, названная "случайным ранним обнаружением" (Random Early Detection, RED) представляет собой механизм профилирования трафика, разработанный сообществом Internet для предотвращения перегрузок на магистрали Internet.
Алгоритм "дырявого ведра"
Алгоритм "дырявого ведра" (Leaky Bucket) разработан для профилирования пульсирующего трафика. Алгоритм позволяет проверить соблюдение трафиком оговоренных значений средней скорости и пульсации.
представляет собой механизм профилирования трафика, разработанный сообществом Internet для предотвращения перегрузок на магистрали Internet.
Алгоритм "Ведро токенов"
Этот алгоритм применяется не для профилирования, а для формирования трафика. Его цель — уменьшение неравномерности продвижения пакетов, когда из-за значительной пульсации они сбиваются в плотные группы.
Алгоритм иллюстрируется
Рисунок 4.5. – Алгоритм "Ведро токенов"
Под токеном в данном случае понимается некий абстрактный объект, носитель "порции" информации, используемый для построения модели обслуживания трафика. Генератор токенов периодически направляет очередной токен в "ведро" с ограниченным объемом в b байт. Все токены имеют одинаковый объем m байт, а генерация токенов происходит с такой скоростью, что "ведро" заполняется со скоростью г байт в секунду. Скорость г является желательной средней скоростью для формируемого трафика. Пакеты поступают в систему и попадают в очередь объемом К байт. Из очереди пакет продвигается управляющим узлом только в том случае, если к этому моменту "ведро" заполнено токенами до уровня не ниже М байт, где М — объем пакета. Если это условие выполняется и пакет продвигается на выход, то из ведра удаляются токены общим объемом в М байт (с точностью до m байт). Если же ведро заполнено недостаточно, то пакет из очереди не выбирается, ожидая поступления нужного числа токенов.
Таким образом достигается "улучшение" трафика: если в результате пульсации в систему приходит большая пачка пакетов, то из очереди пакеты выходят равномерно, в темпе, задаваемом генератором токенов. Поток токенов представляет собой идеальный трафик, к форме которого стараются привести входной трафик.
Протоколы и механизмы поддержки качества обслуживания в сетях IP делятся на две категории в зависимости от уровня гарантий предоставляемого сервиса:
Протоколы первой категории разрабатываются рабочей группой IETF по интегрированным сервисам — Integrated Services Working Group (IntServ). Базовая модель такого сервиса предполагает интегрированное взаимодействие всех устройств сети по обеспечению требуемого качества обслуживания вдоль всего пути потока. Сетевые ресурсы распределяются в соответствии с QoS-запросами приложений и подчиняются политике управления полосой пропускания. В целом модель IntServ соответствует обобщенной модели службы QoS, описанной выше. Наиболее детально проработан протокол сигнализации модели RSVP, с помощью которого конечные узлы выполняют резервирование ресурсов. Его спецификация разработана в 1997 году и имеет статус проекта стандарта Internet.
Направление IntServ разрабатывалось в IETF достаточно давно и было первым направлением, в рамках которого проблема обеспечения QoS в сетях TCP/IP начала решаться систематически. Однако ввиду значительной сложности поддержки интегрированных сервисов в масштабах такой сети, как Internet, получило развитие и другое направление, которое в данный момент ведет рабочая группа по дифференцированным сервисам – Differentiated Services, DiffServ. Эта группа занимается протоколами второй категории, которые не обеспечивают "настоящего" гарантированного качества обслуживания, но зато гораздо проще в реализации.
Сервисы DiffServ опираются на ту же обобщенную модель QoS, что и сервисы IntServ, однако не прибегают к резервированию ресурсов сетевых устройств. Вместо этого они пользуются сигнализацией потребностей потоков в каждом отдельном пакете – поле IP Precedence переносит код, который интерпретируется каждым маршрутизатором сети для приоритетного или взвешенного обслуживания данного потока по отношению к другим. Дифференцированные сервисы пока отстают от интегрированных по степени зрелости протоколов – общее описание архитектуры DiffServ появилось в декабре 1998 года, а первые две детальные спецификации конкретных сервисов – в июне 1999 года.
Интегрированные и дифференцированные сервисы отличаются также объектами приложения QoS. Интегрированные сервисы применяются в основном к отдельным потокам приложений (микропотокам), а дифференцированные – к небольшому числу агрегированных потоков. Поэтому реализация дифференцированных сервисов связана с гораздо более низким уровнем накладных расходов в маршрутизаторах. Маршрутизаторам не требуется запоминать большое количество переменных состояния каждого микропотока сети, а нужно только помнить параметры политики обработки для небольшого количества агрегированных потоков и применять их независимо к каждому пакету. Этот подход близок к традиционному стилю работы маршрутизаторов, когда каждый пакет обрабатывается независимо от состояния сети и конечных узлов.