Маршрутизация в реальном времени

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

Протокол  резервирования ресурсов RSVP.

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

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

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

RSVP не определяет  содержание спецификации потока, он просто передает запрос. Спецификация  потока включает обычно класс  услуг, Rspec (R означает резерв) и Tspec (Т означает трафик). Два других  параметра представляют собой набор чисел. Параметр Rspec определяет требуемое качество услуг, а параметр Tspec описывает поток данных. Содержимое Rspec и Tspec прозрачно для RSVP.

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

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

Многоадресная группа: что делать с данными ?

Основная сложность RSVP связана с многоадресной рассылкой. Пример многоадресной конфигурации приведен на рисунке. Эта конфигурация состоит из четырех маршрутизаторов. Канал между двумя любыми маршрутизаторами, изображаемый линией, может представлять собой как прямой канал, так и подсеть. Три хоста - G1, G2 и G3 - входят в одну группу и получают дейтаграммы с соответствующим групповым адресом. Данные по этому адресу передаются двумя хостами - S1 и S2. Красная линия соответствует дереву маршрутизации для S1 и данной группы, а синия линия для S2 и данной группы. Линии со стрелками указывают направление передачи пакетов от S1 (красная) и от S2 (синяя). 

Все четыре маршрутизатора должны знать о резервировании ресурсов каждым получателем. Таким образом, запросы на выделение ресурсов распространяются в обратном направлении по дереву маршрутизации.

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

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

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

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

Общая схема работы RSVP.

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

1. Получатель вступает в группу многоадресной рассылки посредством отправки сообщения по протоколу IGMP соседнему маршрутизатору.
2. Потенциальный отправитель отправляет сообщение по адресу группы.
3. Получатель принимает сообщение Path, идентифицирующее отправителя.
4. Теперь, когда получатель имеет информацию об обратном пути, он может отправлять сообщения Resv с дескрипторами потока.
5. Сообщения Resv передаются по сети отправителю.
6. Отправитель начинает передачу данных.
7. Получатель начинает прием пакетов данных.

Недостатки RSVP.

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

Дальнейшую  и более полную информацию можно  получить: