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

Маршрутизация в реальном времени: проблемы и возможные решения.

Гиль Настя, 338 группа.

Что такое маршрутизатор

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

Маршрутизация в реальном времени: проблемы и возможные решения.

Гиль Настя, 338 группа.

Что такое маршрутизатор

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

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

Маршрутизатор выполняет целый ряд приложений, причем они могут быть частью сетевой архитектуры или конфигурироваться для удобства администратором сети. Эти приложения, или процессы, выполняются на уровне приложений маршрутизации (Routing Application). Один из таких процессов — доменная служба имен (Domain Name Service, DNS): он кэширует информацию о DNS для обслуживаемых систем. Стандартными сервисами маршрутизаторов являются, например, определение топологии (topology mapping) и управление трафиком (traffic engineering).

Основные понятия.

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

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

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

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

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

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

Маршрутизатор с интеграцией услуг.

Маршрутизатор с интеграцией услуг должен поддерживать протокол резервирования ресурсов (Resource Reservation Protocol, RSVP). Маршрутизаторы этого типа добавляют протокол ресурсов, контрольный модуль и интерфейс к политике очередей уровня коммутации.

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

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

Где важно реальное время

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

Иначе обстоит дело с так называемыми приложениями реального времени.

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

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

Переход в режим реального времени

Т.о. современные приложения не могут допустить, чтобы их пакеты поступали с опозданием. Два протокола позволяют гарантировать своевременность доставки с обеспечением качества услуг – это протоколы RTP( Real-Time Transport Protocol) и RSVP (Resource Reservation Protocol) .

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

Почему нельзя использовать стандартные протоколы ?

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

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

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

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

Транспортный протокол реального времени RTP.

Несмотря на то, что каждое приложение реального времени может иметь свои собственные механизмы для поддержки передачи в реальном времени, они имеют много общих черт, а это делает желательным определение единого протокола. Стандартный протокол такого рода – RTP, определенный в RFC 1889.

Реальность реального времени.

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

Многоадресная передача.

RTP поддерживает передачу данных в реальном времени между несколькими участниками сеанса. ( Сеанс — это логическое объединение двух и более объектов RTP, которые обслуживаются при передачи данных.)

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

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

Пример приложения для микшера — комбинирование нескольких источников звука. Например, пусть часть систем данного аудиосеанса генерирует каждая свой собственный поток RTP. Большую часть времени только один источник активен, хотя время от времени одновременно «говорят» несколько источников.

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

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

Заголовки RTP.

TCP – это общепринятый в Internet’е протокол транспортного уровня. Как уже было сказано, у него нет возможности контролировать задержки при доставке пакетов. RTP обходит ограничения TCP за счет использования UDP в качестве транспортного уровня для видеоконференций и других сервисов реального времени.

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

Первые 12 октетов заголовка состоят из следующих полей:

• поле версии (2 бита): текущая версия вторая;

• поле заполнения (1 бит): это поле сигнализирует о наличии заполняющих октетов в конце полезной нагрузки. (Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам.) В этом случае последний октет указывает число заполняющих октетов;

• поле расширения заголовка (1 бит): когда это поле задано, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP;

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

• поле маркера (1 бит): смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания;

• поле типа полезной нагрузки (7 бит): это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol);

• поле порядкового номера (16 бит): каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент (например, пакеты, принадлежащие к одному и тому же видеокадру);

• поле отметки о времени (32 бита): здесь записывается момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя;

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

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

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

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

Проблемы перегрузки сети.

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

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

Превентивные меры полезны как при одноадресной, так и при многоадресной передаче.

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

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

Протокол резервирования ресурсов 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 распадается на части.

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

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

Маршрутизатор выполняет целый ряд приложений, причем они могут быть частью сетевой архитектуры или конфигурироваться для удобства администратором сети. Эти приложения, или процессы, выполняются на уровне приложений маршрутизации (Routing Application). Один из таких процессов — доменная служба имен (Domain Name Service, DNS): он кэширует информацию о DNS для обслуживаемых систем. Стандартными сервисами маршрутизаторов являются, например, определение топологии (topology mapping) и управление трафиком (traffic engineering).

Основные понятия.

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

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

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

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

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

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

Маршрутизатор с интеграцией услуг.

Маршрутизатор с интеграцией услуг должен поддерживать протокол резервирования ресурсов (Resource Reservation Protocol, RSVP). Маршрутизаторы этого типа добавляют протокол ресурсов, контрольный модуль и интерфейс к политике очередей уровня коммутации.

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

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

Где важно реальное время

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

Иначе обстоит дело с так называемыми приложениями реального времени.

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

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

Переход в режим реального времени

Т.о. современные приложения не могут допустить, чтобы их пакеты поступали с опозданием. Два протокола позволяют гарантировать своевременность доставки с обеспечением качества услуг – это протоколы RTP( Real-Time Transport Protocol) и RSVP (Resource Reservation Protocol) .

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

Почему нельзя использовать стандартные протоколы ?

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

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

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

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

Транспортный протокол реального времени RTP.

Несмотря на то, что каждое приложение реального времени может иметь свои собственные механизмы для поддержки передачи в реальном времени, они имеют много общих черт, а это делает желательным определение единого протокола. Стандартный протокол такого рода – RTP, определенный в RFC 1889.

Реальность реального времени.

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

Многоадресная передача.

RTP поддерживает передачу данных в реальном времени между несколькими участниками сеанса. ( Сеанс — это логическое объединение двух и более объектов RTP, которые обслуживаются при передачи данных.)

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

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

Пример приложения для микшера — комбинирование нескольких источников звука. Например, пусть часть систем данного аудиосеанса генерирует каждая свой собственный поток RTP. Большую часть времени только один источник активен, хотя время от времени одновременно «говорят» несколько источников.

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

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

Заголовки RTP.

TCP – это общепринятый в Internet’е протокол транспортного уровня. Как уже было сказано, у него нет возможности контролировать задержки при доставке пакетов. RTP обходит ограничения TCP за счет использования UDP в качестве транспортного уровня для видеоконференций и других сервисов реального времени.

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

Первые 12 октетов заголовка состоят из следующих полей:

• поле версии (2 бита): текущая версия вторая;

• поле заполнения (1 бит): это поле сигнализирует о наличии заполняющих октетов в конце полезной нагрузки. (Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам.) В этом случае последний октет указывает число заполняющих октетов;

• поле расширения заголовка (1 бит): когда это поле задано, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP;

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

• поле маркера (1 бит): смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания;

• поле типа полезной нагрузки (7 бит): это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol);

• поле порядкового номера (16 бит): каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент (например, пакеты, принадлежащие к одному и тому же видеокадру);

• поле отметки о времени (32 бита): здесь записывается момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя;

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

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

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

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

Проблемы перегрузки сети.

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

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

Превентивные меры полезны как при одноадресной, так и при многоадресной передаче.

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

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

Протокол резервирования ресурсов 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 распадается на части.

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