Групповое вещание в IP-сетях

Следующие опции позволяют управлять выбором отправителей:

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

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

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

 

 

 

 

8.   Обработка ошибок

Сообщения протокола RSVP отсылаются ненадежно, поскольку программа напрямую работает с IP, так же как с IGMP или ICMP. Сообщения об ошибках в RSVP - это сообщение ошибки маршрута (PathErr) и сообщение ошибки резервирования (ResvErr). Процесс прост: сообщение отсылается выше по дереву отправителю, вызвавшему ошибку.

 

9.   Слияние спецификаторов потока

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

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

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

 

10. Пример

Прежде чем создавать сеанс, его следует определить, что реализуется при помощи параметров destaddress (целевой адрес), protocolid (идентификатор протокола) и destport (целевой порт), которые должны быть переданы всем отправителям и получателям. Последовательность событий следующая:

1.   Приемник присоединяется  к адресуемой группе посредством  протокола IGMP.

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

3.   Приемник отсылает сообщение  о резервировании, задавая требуемые  дескрипторы потока. Их примет отправитель.

4.   Отправитель начинает передавать пакеты данных.

Как только запрос будет принят и обработан, начнется резервирование ресурсов, которые, однако, останутся в промежуточном положении (soft state): имеется информация о резервировании, но для ее поддержания требуются определенные действия. При отсутствии таких действий информация будет удалена.

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

На рисунке 4.6. пример использования RSVP в групповой среде.

 

Рисунок 4.6. – Использования RSVP в групповой среде

 

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

 

Рисунок 4.7. – Использования RSVP в групповой среде

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

•  Резервирование производится приемниками по направлению потока основного трафика обратно к отправителю.

• Резервирование происходит главным образом за счет ресурсов сетевого слоя во взаимоподключаемых устройствах (т.е. маршрутизаторах или устройствах, выполняющих их функции).

• RSVP функционирует  поверх IP, занимая  место транспортного протокола, и работает подобно протоколу управления Internet, сходному с ICMP.

• Поддерживает многоадресные и однонаправленные протоколы: 

• Рассчитан на управление большими, неоднородными группами пользователей с динамическим членством и топологией.

• RSVP - однонаправленный протокол, он производит резервирование лишь в одном направлении потока данных

• Как только происходит резервирование, оно поддерживается использованием мягких состояний в маршрутизаторах.

• Мягкое состояние обеспечивает постепенную   поддержку   изменений членства и адаптацию к изменениям  маршрутизатора.

 

11. Проблемы

Не окажется ли маршрутизатор перегруженным, если каждый приемник делает запросы RSVP? Нет. Во-первых, любой маршрутизатор может отказать в запросе Во-вторых, RSVP в маршрутизаторе поддерживается при помощи промежуточных положений Резервирование будет отменено, если оно больше не нужно. В-третьих, RSVP позволяет применить концепцию объединения (merging), в соответствии с которой разрешается объединять (совместно применять) запросы, когда равнозначное резервирование уже было проведено.

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

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

 

8. Дифференцированное обслуживание DiffServ.

 

Дифференцированные сервисы представляют собой простой и весьма грубый метод классификации требований к качеству обслуживания небольшого числа агрегированных потоков сети. Основная идея, положенная в основу этой группы сервисов QoS, состоит в том, чтобы все маршрутизаторы сети единообразно понимали закодированные в 5 битах поля TOS протокола IPv4 (или поля Traffic Class протокола IPv6) требования к качеству обслуживания. Дифференцированные сервисы не используют резервирования ресурсов в маршрутизаторах, поэтому не могут дать гарантий на предоставляемое качество обслуживания, реализуя только "мягкую" поддержку QoS. Каждый маршрутизатор работает независимо от остальных и старается обеспечить предпочтительное качество обслуживания потоков. Пять бит, отводимые для кодирования требований к качеству обслуживания, определяют, что в сети может существовать не более 32 агрегированных потоков, отличающихся предоставляемым качеством обслуживания.

Обобщенно поле, переносящее коды качества обслуживания в протоколах IP разных версий, называется DS-байтом. Упомянутые ранее 5 бит составляют старшую часть этого поля, а оставшиеся 3 бита пока не используются. Для протокола IPv4 DS-байт является байтом TOS (рис. 4.8).

Рисунок 4.8. – Структура TOS-байта.

 

Значения поля IP Precedence (0-2) определяют приоритетность трафика, причем значению 111 этих бит соответствует самый приоритетный класс трафика, а значению 000 — самый низкоприоритетный. Оставшиеся два бита определяют предпочтительность отбрасывания пакетов при перегрузках.

 

1.   Технология DiffServ в сетях Ethernet

Основная идея технологии DiffServ (Differential Services) заключается в разделении трафика в сети на несколько крупных классов, для каждого из которых будет обеспечиваться определенный QoS в рамках некоторой области, называемой доменом DiffServ. На границах домена происходит кондиционирование трафика, то есть его классификация, подразумевающая анализ входящих пакетов, сопоставление полученной информации с таблицей потоков, а также маркировка пакетов специальным кодовым словом DSCP (DiffServ Code Point). Данные функции выполняет так называемый порт доступа в домен (port-access).  
Далее обработка трафика на промежуточных узлах, принятие решения о направлении пакета в ту или иную очередь осуществляется исключительно по кодовому слову DSCP, расположенному в заголовке пакета IP (поле TOS). Обработка классифицированного трафика внутри домена осуществляется со скоростью коммутации – достаточно считать 6 бит кодового слова и отправить пакет в соответствующую очередь, после чего вступает в действие алгоритм «взвешенного справедливого обслуживания» (или любой другой, кроме FIFO) описанный выше.

Возможны различные реализации данного алгоритма в оборудовании разных производителей. Например, в маршрутизаторах Cisco компании Cisco Systems для классификации используется два младших бита из трехразрядного подполя IP Precedence поля TOS. По умолчанию, классу 0 выделяется 10% полосы пропускания, классу 1, 2 и 3 – 20%, 30% и 40% соответственно. Для очередей, основанных на классах QoS, пакеты, не назначенные ни в одну группу, принадлежат группе 0 и автоматически имеют 1% от общей пропускной способности на всю группу. Общий вес остальных групп не может превышать 99%, а если после назначения всех весов остается свободная полоса пропускания в канале, она автоматически отводится под группу 0.

Другой пример реализации - коммутаторы OptiSwitch компании Optical Access, которые предлагают администратору при настройке параметров QoS выбрать один из режимов работы с 4-мя очередями:

1. взвешенное круговое обслуживание (Weighted Round Robin, WRR)
2. смешанное обслуживание 1/3
3. смешанное обслуживание 2/2
4. обслуживание с прямым приоритетом (Strict Priority, SP)

В первом случае, каждой очереди назначаются весовые коэффициенты, задаваемые в количестве пакетов или байтов (по умолчанию 1, 2, 3 и 4), в соответствии с которыми происходит продвижение пакетов из очередей. Так, по умолчанию, из высокоприоритетной очереди в выходной буфер будет перенаправляться четыре пакета, а из низкоприоритетной - один. В случае использования механизма прямого приоритета (пункт 4) будет действовать довольно грубое, но эффективное правило – очереди с более низким приоритетом не обслуживаются, если есть хотя бы один необработанный пакет в высокоприоритетной очереди. Во втором и третьем случае имеет место смешанное обслуживание, когда часть очередей работает по WRR-алгоритму, а часть – по SP.

Другим важным средством обеспечения QoS в технологии DiffServ является механизм формирования трафика. Данный механизм предназначен для сглаживания пульсаций «взрывного» трафика, уменьшения неравномерности продвижения пакетов. В аппаратной реализации стандарта DiffServ используется механизм, работающий по алгоритму «token bucket» или «маркерное ведро», описанный ранее.

 

2.   Поддержка стандарта DiffServ в коммутаторах OptiSwitch компании Оptical Access.

Итак,  речь об этих коммутаторах зашла лишь потому, что сеть, на базе которой планируется вещание построена на таких коммутаторах.

Компания Optical Access, реализовав в своем семействе коммутаторов OptiSwitch поддержку стандарта DiffServ, предложила решение OptiSwitch Classifier, обеспечивающие все необходимые функции и услуги операторского уровня. Концепция OptiSwitch Classifier полностью соответствует стандарту DiffServ.