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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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