Сегодня мы рассмотрим: Настоящие ценители музыки знают, что для качественного...
Протоколы RTP и RTCP в VoIP
RTP является основным транспортным протоколом в сетях IP-телефонии.
RTP (Real Time Protocol) - протокол реального времени, был создан для
передачи мультимедийной (ауди, видео), закодированной и упакованной в
пакеты, информации по IP сетям в строгих временных рамках. Передача
сегментов RTP происходит поверх протокола UDP и IP, соответственно на
разных уровнях модели OSI. Использования протокола UDP, не
гарантирующего доставку, связано со строгими временными рамками передачи
мультимедийной информации в реальном времени, а также неспособностью
протокола TCP работать в режиме реального времени. Поэтому не смотря на
потерю части данных своевременность доставки более важна в данном
случае.
В общем виде распределение протоколом по уровням модели OSI выглядит следующим образом:
Транспортный уровень: RTP поверх UDP
Сетевой: IP
Канальный: Ethernet
Физический: Ethernet
При передачи мультимедийной информации с использованием протокола RTP используется инкапсуляция следующего вида:
Минимальным размером RTP сегмента является 12 байт. Первые два бита
определяют версию протокола. На сегодняшний день используется RTPv.2 .
Следующее поле Р также имеет размер 2 бита и указывает на наличие
символов заполнителей в поле данных, при использовании сегментов
одинаковой длинны. Поле X определяет используется ли расширенный
заголовок. Затем поле СС, состоящее из 4 бит, определяет число
CSRC-полей в конце RTP заголовка, т. е. число источников, формирующих
поток. Затем идет поле М - маркерный бит, использующийся для выделения
важных данных. Следующее поле РТ имеет размер 7 бит. Предназначено для
определения типа полезной нагрузки - данные необходимые для приложения.
По указанному коду приложение определяет тип мультимедийной информации и
способ декодирования.
Остальная часть заголовка состоит из поля порядкового номера
(SequenceNumber) - последовательный номер сегмента, который отслеживает
порядок пакетов и их потерю; поля метки времени (Time Stamp) - код
синхронизации, указывающий на момент времени первой кодированной выборки
в полезной нагрузке, данная отметка используется буферами
восстановления синхронизации для ликвидации потерь качества, вызванного
вариацией задержки; поля источника синхронизации SSRC - произвольное
число, отличающее один RTP-сеанс от другого, для создания возможности
мультиплексирования. После постоянной фиксированной части
RTP-заголовка могут добавляться до 15 тридцати двух разрядных
CSRC-полей, которые идентифицируют источники данных.
Опишем процедуру установления RTP сеанса. Протоколом установлено, что
трафик разного типа передается в отдельных сеансах связи. Для
установления сеанса необходимо определить пару транспортных адресов
назначения т.е. один сетевой адрес и два порта для RTP и RTCP. Так для
видеоконференции необходимо аудио и видео передавать в разных сеансах с
соответственно разными портами назначения. Передача разных типов
трафика с использованием перемежения в одном сеансе могло бы вызвать
следующие проблемы:
- при изменении одного из типов трафика невозможно определить какой параметр в сеансе необходимо заменить на новое значение;
- для установления сеанса используется только один интервал тайминга, а
при передачи разнородного трафика у каждого типа будет свой интервал, и
они будут различаться;
- микшер RTP не может объединять перемеженные потоки различных типов трафика в один поток;
- передаче нескольких типов трафика в одном сеансе RTP невозможно по
следующим причинам: применение различных сетевых путей или распределение
сетевых ресурсов; прием подмножества мультимедийных данных, когда это
требуется, например, только звука, если видеосигнал превысил доступную
полосу пропускания; реализации приемника, которые используют отдельные
процессы для различных типов трафика, в то время как использование
отдельных сеансов RTP допускает реализации как с одним, так и с
множеством процессов.
Однако протокол RTP (Real-time Transport Protocol) и UDP (User
Datagram Protocol) не гарантируют качество, т.е не работают с QoS
(Quality of Service). Поэтому протокол RTP поддерживается протоколом
RTCP (Real-Time Transport Control Protocol), который предоставляет
дополнительную информацию о состоянии сеанса связи RTP.
Протокол RTCP выполняет четыре основные функции:
I. Основная задача протокола RTCP - это обеспечение обратной связи для
гарантирования качества при передаче данных. Обратная связь может быть
непосредственно полезна при применении при передаче адаптивного
кодирования. Также при использовании IP мультикастинга для получателей
крайне важно диагностировать ошибки при передаче сообщений(пакетов).
Посылка сообщений с отчетами о приеме позволяют передающей стороне
определить причину неудачной передачи сообщений, в случаи возникновении
таковой.
II. RTCP содержит неизменяемый идентификатор транспортного уровня для
RTP источника, который имеет название «каноническое имя» или «Сname»
(Canonical Name). Так как SSRC-идентификатор может быть изменятся, в
случае нахождения коллизий (столкновений) , для получателя необходимо
значение Сname, для того чтобы отслеживать каждого из участников.
Получателям также использует Cname, чтобы установить соответствие между
многими потоками данных от одного участника при установлении нескольких
сессий одновременно, например, чтобы синхронизовать аудио и видео каналы
при передаче видео со звуком.
III. Перечисленные выше две функции подразумевают, что все участники
сеансов посылали RTCP-пакеты, поэтому скорость передачи должна
контролироваться для того, чтобы RTP мог устанвливать сеансы с большим
числом пользователей. При передаче каждым участником своих управляющих
пакетов всем остальным любой партнер может независимо определить полное
число участников сессии. Это необходимо для расчетов частоты передачи
сообщений RTCP.
IV. Данная функция служит для передачи минимально необходимой
управляющей информации, такой как идентификатор участников, которая
используется графическим интерфейсом пользователя. Эта функция
используется для слабо контролируемых сессий, когда пользователи входят и
выходят без должного согласование параметров и характеристик. RTCP
выполняет функции удобного канала для контакта со всеми участниками, но
он необязательно поддерживает все коммуникационные требования
приложения.
В IP сетях с использованием мультикастинга функции один, два и три
являются обязательными при использовании RTP сессий. Также рекомендуется
их использование и при передаче в прочих сетях и средах. На сегодняшний
день рекомендуется разработчикам приложений RTP использовать средства
позволяющие работать в мультикастном режиме, а не только в уникастном.
Рассмотрим формат пакетов RTCP.
Стандартом протокола определено несколько типов пакетов RTCP. RTCP предназначен для передачи служебной информации:
sr: Отчет отправителя. Необходим для статистики приема и передачи
участников сеанса, которые непосредственно являются активными
отправителями;
rr: Отчет получателя. Необходим для статистики от участников, которые не являются получателями;
sdes: Описывает источник, включает Cname;
bye: Служит для индикации завершения (выхода) сеанса;
app: Специфические функции приложений;
Каждый RTCP пакет состоит из постоянной части, как и для протокола RTP,
которая используется RTP-пакетами, за ней следуют поля, которые могут
изменяться по длинне в зависимости от типа пакета, но кратную 32 бит.
Требования выравнивания и поле длины в фиксированной части заголовка
введены для того, чтобы сделать RTCP-пакеты объединяемыми. Несколько
RTCP-пакетов могут быть соединены друг с другом без введения каких-либо
сепараторов, для того чтобы получить составной RTCP-пакет, который
посылается в рамках транспортного протокола низкого уровня, например
UDP. Не существует специального счетчика индивидуальных RTCP-пакетов,
так как протокол низкого уровня задаст общую длину и определит конец
составного пакета.
Формат RTCP пакета сообщения отправителя выглядит следующим образом, как показано на рисунке выше.
Пакеты RTCP подвергаются следующим проверкам на корректность.
- RTP поле версии должно быть равно 2.
- Поле типа данных первого RTCP пакета в составном пакете должно быть SR или RR.
- Бит заполнителя (P) должен быть равен нулю для первого пакета
составного RTCP пакета, так как заполнитель может присутствовать только в
последнем.
- Длина полей индивидуальных RTCP-пакетов должна в сумме равняться полной длине составного пакета.
RTP - Протокол передачи медиаданных в реальном времени (Real-time Transport Protocol) RTCP - Протокол передачи управляющих данных в реальном времени (Real-time Control Protocol)
Дополнительно включает в себя информацию о: Потерях пакетов Буферизация "Jitter" Задержки Уровень сигнала Метрика качества сигнала (Call Quality Metrics) Echo Return Loss и т.д. RTCP XR -Расширенный Протокол передачи управляющих данных в реальном времени (Real-time Control Protocol Extended Reports)
Все поля, описанные для протокола RTCP, плюс: R Factor - Параметр качества сигнала MOS - Параметр качества сигнала и другие
Пакеты, содержащие передаваемый голос, передаются с использованием RTP/RTCP для протокола , который используется для VOIP вызовов. Протокол RTP может передавать медиаданные, идентифицируемые параметрами, которые зарегистрированы организацией: "Internet assigned numbers authority" - IANA. Они так же используются для полей в протоколе , который используется в и сообщениях.
Некоторые значения поля payload:
| PT | название кодека | audio/video (A/V) | clock rate (Hz) | кол-во каналов | Документ | 0 | PCMU | A | 8000 | 1 | RFC3551 | 3 | GSM | A | 8000 | 1 | RFC3551 | 4 | G723 | A | 8000 | 1 | Kumar | 5 | DVI4 | A | 8000 | 1 | RFC3551 | 6 | DVI4 | A | 16000 | 1 | RFC3551 | 7 | LPC | A | 8000 | 1 | RFC3551 | 8 | PCMA | A | 8000 | 1 | RFC3551 | 9 | G722 | A | 8000 | 1 | RFC3551 | 10 | L16 | A | 44100 | 2 | RFC3551 | 11 | L16 | A | 44100 | 1 | RFC3551 | 12 | QCELP | A | 8000 | 1 | - | 13 | CN | A | 8000 | 1 | RFC3389 | 14 | MPA | A | 90000 | RFC3551,RFC2250 | 15 | G728 | A | 8000 | 1 | RFC3551 | 16 | DVI4 | A | 11025 | 1 | DiPol | 17 | DVI4 | A | 22050 | 1 | DiPol | 18 | G729 | A | 8000 | 1 | 19 | зарезервировано | A | 20 | не назначено | A | 21 | не назначено | A | 22 | не назначено | A | 23 | не назначено | A | 24 | не назначено | V | 25 | CelB | V | 90000 | RFC2029 | 26 | JPEG | V | 90000 | RFC2435 | 27 | не назначено | V | 28 | nv | V | 90000 | RFC3551 | 29 | не назначено | V | 30 | не назначено | V | 31 | H261 | V | 90000 | RFC2032 | 32 | MPV | V | 90000 | RFC2250 | 33 | MP2T | AV | 90000 | RFC2250 | 34 | H263 | V | 90000 | Zhu | 35--71 | не назначено | 72--76 | зарезервировано для RTCP во избежание конфликтов | RFC3550 | 77--95 | не назначено | 77--95 | dynamic | RFC3551 |
IANA: Зарегистрированные параметры протокола RTP: http://www.iana.org/assignments/rtp-parameters
Протокол RTP и трансляция IP адресов (NAT) При проведении VOIP сеанса связи, образуются два RTP потока, по одному в каждом направлении. Если один из участников, участвующий в этом сеансе, использует IP адрес из приватной сети, тогда поток от абонента, находящегося в публичной сети в сторону NAT сервера, не сможет достичь абонента, находящегося во внутренней сети. Для решения этой проблемы часто используется (симметричный RTP). Для дополнительной информации об использовании VOIP в сетях с NAT, смотри: NAT and VOIP.Статьи RTCP XR measures VoIP performance Network World 11/17/03Документы RFC: IETF RFC 3550 RTP: Транспортный протокол для приложений, работающих в реальном времени. IETF RFC 3611 RTP Control Protocol Extended Reports (RTCP XR) IETF RFC 1890 RTP профиль для звуковых и видео конференций с Минимальным управлением. IETF RFC 2508 Сжатие заголовков IP/UDP/RTP пакетов для низкоскоростных линий связи. IETF RFC 3545 Расширенная компрессия RTP (CRTP) для линий связи с высокими задержками, большими потерями пакетов и частой повторной отправкой данных.Когда мы, разговаривая по IP телефону, слышим голос собеседника в трубке, или, используя систему видеоконференцсвязи, общаемся со своими коллегами и родственниками, то обмениваемся непрерывным потоком данных. При передаче потоковых данных, таких как голос и видео через пакетную сеть, очень важно использовать такие механизмы, которые решали бы следующие задачи:
- Устранение эффекта потери пакетов
- Восстановление порядка и контроль поступления пакетов
- Сглаживание эффекта задержки (джиттера)
Именно для этих целей был разработан RTP (Real-time Transport Protocol) - протокол передачи в реальном времени, о котором пойдет речь в сегодняшней статье. Протокол разрабатывался в IETF группой Audio-Video Transport Working Group и описывается в рекомендации RFC 3550.
Как правило, RTP работает поверх протокола UDP (User Datagram Protocol), так как при передаче мультимедийных данных очень важно обеспечить их своевременную доставку.
RTP включает возможность определения типа полезной нагрузки и назначения последовательного номера пакета в потоке, а также применение временных меток.
На передающей стороне каждый пакет помечается временной меткой, принимающая сторона получает ее и определяет суммарную задержку, после чего вычисляется разница в суммарных задержках и определяется джиттер. Таким образом, появляется возможность установить постоянную задержку выдачи пакетов и тем самым снизить влияние джиттера.
Ещё одна функция RTP связана с возможными потерями пакетов при прохождении по IP сети, что выражается в появлении кратковременных пауз в разговоре. Внезапная тишина в телефонной трубке, как правило, очень негативно действует на слушателя, поэтому возможностями протокола RTP такие периоды тишины заполняются, так называемым,“комфортным шумом”
RTP работает в связке с еще одним протоколом IETF, а именно RTCP (Real - time Transport Control Protocol), который описывается в RFC 3550. RTCP предназначен для сбора статистической информации, определения качества обслуживания QoS (Quality of Service), а также для синхронизации между медиа потоками RTP-сессии.
Основная функция RTCP – установление обратной связи с приложением для отчета о качестве получаемой информации. Участники RTCP сессии обмениваются сведениями о числе полученных и утраченных пакетов, значении джиттера, задержке и т.д. На основе анализа этой информации принимается решение об изменении параметров передачи, например, для уменьшения коэффициента сжатия информации с целью улучшения качества ее передачи.
Для выполнения этих функций RTCP передает специальные сообщения определенных типов:
- SR - Sender Report - отчёт источника со статистической информацией о RTP сессии
- RR - Receiver Report - отчёт получателя со статистической информацией о RTP сессии
- SDES - содержит описание параметров источника, включая cname (имя пользователя)
- BYE – Инициирует завершение участия в группе
- APP - Описание функций приложения
RTP является протоколом однонаправленного действия, поэтому для организации двусторонней связи необходимо две RTP сессии, по одной с каждой стороны.
RTP-сессия определяется IP адресами участников, а также парой незарезервированных UDP портов из диапазона 16384 - 32767. Кроме того, для организации обратной связи с приложением необходимо также установить двустороннюю RTCP сессию. Для RTCP сессии занимаются порты с номером на единицу большим чем RTP. Так например, если для RTP выбран 19554 порт, то RTCP сессия займет 19555 порт. Наглядно формирование RTP/RTCP сессии представлено на рисунке ниже.
Протоколы RTP и RSVP, http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.htmlСовременные приложения не могут допустить, чтобы их пакеты поступали с опозданием. Два протокола (RTP и PSVP) позволяют гарантировать своевременность доставки с обеспечением качества услуг.
Непрекращающийся рост Интернета и частных сетей предъявляет новые требования к пропускной способности. Клиент-серверные приложения далеко превосходят Telnet по объемам передаваемых данных. World Wide Web привел к гигантскому увеличению графика графической информации. Сегодня к тому же голосовые и видеоприложения выдвигают свои специфические требования к и без того перегруженным сетям.
Для того чтобы удовлетворить все эти запросы, одного увеличения емкости сети недостаточно. Что действительно необходимо, так это разумные эффективные методы управления графиком и контроль загруженности.
Исторически сети на базе IP предоставляли всем приложениям только простейшую услугу по доставке данных по мере возможности. Однако потребности со временем изменились. Организации, потратившие миллионы долларов на установку сети на базе IP для передачи данных между локальными сетями, сталкиваются теперь с тем, что такие конфигурации не способны эффективно поддерживать новые мультимедийные приложения реального времени с многоадресной рассылкой.
АТМ - единственная сетевая технология, которая изначально разрабатывалась для поддержки обычного трафика TCP и UDP наряду с трафиком реального времени. Однако ориентация на АТМ означает либо создание новой сетевой инфраструктуры для трафика реального времени, либо замену имеющейся конфигурации на базе IP, причем оба варианта обойдутся весьма недешево.
Поэтому потребность в поддержке нескольких типов трафика с различными требованиями к качеству услуг в рамках архитектуры TCP/IP весьма насущна. Эту задачу призваны решить два ключевых инструмента: транспортный протокол реального времени (Real-Time Transport Protocol, RTP) и протокол резервирования ресурсов (Resource Reservation Protocol, RSVP).
RTP гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах. Это означает, что данные могут быть воспроизведены в реальном времени. RSVP позволяет конечным системам резервировать сетевые ресурсы для получения необходимого качества услуг, в особенности ресурсы для трафика реального времени по протоколу RTP.
Наиболее широко используемый протокол транспортного уровня - это TCP. Хотя TCP позволяет поддерживать множество разнообразных распределенных приложений, он не подходит для приложений реального времени.
В приложениях реального времени отправитель генерирует поток данных с постоянной скоростью, а получатель(-и) должен предоставлять эти данные приложению с той же самой скоростью. Такие приложения включают аудио- и видеоконференции, распространение живого видео (для немедленного воспроизведения), разделяемые рабочие области, удаленную диагностику в медицине, компьютерную телефонию, распределенное интерактивное моделирование, игры и мониторинг в реальном времени.
Использование TCP в качестве транспортного протокола для этих приложений невозможно по нескольким причинам. Во-первых, данный протокол позволяет установить соединение только между двумя конечными точками и, следовательно, не подходит для многоадресной передачи. Он предусматривает повторную передачу потерянных сегментов, прибывающих в то время, когда приложение реального времени уже их не ждет. Кроме того, у TCP нет удобного механизма привязки информации о синхронизации к сегментам, что также является требованием приложений реального времени.
Другой широко используемый протокол транспортного уровня - UDP не имеет первых двух
ограничений (соединение «точка-точка» и передача потерянных сегментов), но и он не предоставляет критической информации о синхронизации. Таким образом, UDP сам по себе не имеет каких-либо инструментов общего назначения для приложений реального времени.
Несмотря на то что каждое приложение реального времени может обладать своими собственными механизмами для поддержки передачи в реальном времени, они имеют много общих черт, что делает определение единого протокола весьма желательным. Стандартный протокол такого рода - RTP, определенный в RFC 1889.
В типичной среде реального времени отправитель генерирует пакеты с постоянной скоростью. Они отправляются им через одинаковые интервалы времени, проходят через сеть и принимаются получателем, воспроизводящим данные в реальном времени по их получении.
Однако ввиду вариации задержки при передаче пакетов по сети они прибывают через нерегулярные интервалы. Для компенсации этого эффекта поступающие пакеты буферизуются, придерживаются на некоторое время и затем предоставляются с постоянной скоростью программному обеспечению, генерирующему вывод. Чтобы такая схема работала, каждый пакет получает отметку о времени - таким образом получатель может воспроизвести поступающие данные с той же скоростью, что и отправитель.
RTP поддерживает передачу данных в реальном времени между несколькими участниками сеанса. (Сеанс - это логическая связь между двумя и более пользователями RTP, поддерживаемая в течение всего времени передачи данных. Процесс открытия сеанса выходит за рамки RTP.)
Хотя RTP может использоваться и для одноадресной передачи в реальном времени, его сила - в поддержке многоадресной передачи. Для этого каждый блок данных RTP содержит идентификатор отправителя, указывающий, кто из участников генерирует данные. Блоки данных RTP содержат также отметку о времени, чтобы данные могли быть с правильными интервалами воспроизведены принимающей стороной.
Кроме того, RTP определяет формат полезной нагрузки передаваемых данных. С этим напрямую связана концепция синхронизации, за которую частично отвечает микшер - механизм трансляции RTP. Принимая потоки пакетов RTP от одного или более источников, он комбинирует их и посылает новый поток пакетов RTP одному или более получателям. Микшер может просто комбинировать данные, а также изменять их формат.
Пример приложения для микшера - комбинирование нескольких источников звука. Например, предположим, что часть систем данного аудиосеанса генерирует каждая свой собственный поток RTP. Большую часть времени только один источник активен, хотя иногда одновременно «говорят» несколько источников.
Если новая система хочет принять участие в сеансе, но ее канал до сети не имеет достаточной точной емкости для поддержки всех потоков RTP, то микшер получает все эти потоки, объединяет их в один и передает последний новому члену сеанса. При получении нескольких потоков микшер складывает значения импульсно-кодовой модуляции. Заголовок RTP, генерируемый микшером, включает идентификатор(-ы) отправителя(-ей), чьи данные присутствуют в пакете.
Более простое устройство создает один исходящий пакет RTP для каждого поступающего пакета RTP. Этот механизм, называемый транслятором, может изменить формат данных в пакете или использовать иной комплект низкоуровневых протоколов для передачи данных из одного домена в другой. Например, потенциальный получатель может оказаться не в состоянии обрабатывать высокоскоростной видеосигнал, используемый другими участниками сеанса. Тогда транслятор конвертирует видео в формат более низкого качества, требующий не такой высокой скорости передачи данных.
Каждый пакет RTP имеет основной заголовок, а также, возможно, дополнительные поля, специфичные для приложения. Рис. 4 иллюстрирует структуру основного заголовка. Первые 12 октетов состоят из следующих полей:
- поле версии (2 бита): текущая версия - вторая;
- поле заполнения (1 бит): это поле сигнализирует о наличии заполняющих октетов в конце полезной нагрузки. (Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам.) В этом случае последний октет указывает число заполняющих октетов;
- поле расширения заголовка (1 бит): когда это поле задано, то за основным заголовком следует еще один, дополнительный, используемый в экспериментальных расширениях RTP;
- поле числа отправителей (4 бита): это поле содержит число идентификаторов отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком;
- поле маркера (1 бит): смысл бита маркера зависит от типа полезной нагрузки. Бит маркера используется обычно для указания границ потока данных. В случае видео он задает конец кадра. В случае голоса он задает начало речи после периода молчания;
- поле типа полезной нагрузки (7 бит): это поле идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления передачей в реальном времени (Real-Time Transport Control Protocol);
- поле порядкового номера (16 бит): каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент (например, пакеты, принадлежащие одному и тому же видеокадру);
- поле отметки о времени (32 бита): здесь записывается момент времени, когда был создан первый октет данных полезной нагрузки. Единицы, в которых в этом поле указывается время, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя;
- поле идентификатора источника синхронизации: генерируемое случайным образом число, уникальным образом идентифицирующее источник в течение сеанса.
За основным заголовком может следовать одно или более полей идентификаторов отправителей, чьи данные присутствуют в полезной нагрузке. Эти идентификаторы вставляются микшером.
Протокол RTP используется только для передачи пользовательских данных - обычно многоадресной - всем участникам сеанса. Отдельный протокол управления передачей в реальном времени (Real-Time Transport Control Protocol, RTCP) работает с несколькими адресатами для обеспечения обратной связи с отправителями данных RTP и другими участниками сеанса.
RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта. Каждый участник сеанса периодически посылает RTCP-пакет всем остальным участникам сеанса. RFC 1889 описывает три функции, выполняемые RTCP.
Первая функция состоит в обеспечении качества услуг и обратной связи в случае перегрузки. Поскольку RTCP-пакеты являются многоадресными, то все участники сеанса могут оценить, насколько хороши работа и прием других участников. Сообщения отправителя позволяют получателям оценить скорость данных и качество передачи. Сообщения получателей содержат информацию о проблемах, с которыми они сталкиваются, включая утерю пакетов и избыточную неравномерность передачи. Например, скорость передачи для аудио-/видеоприложения может быть снижена, если линия не обеспечивает желаемого качества услуг при данной скорости передачи.
Обратная связь с получателями важна также для диагностирования ошибок при распространении.
Анализируя сообщения всех участников сеанса, администратор сети может определить, касается ли данная проблема одного участника или носит общий характер.
Вторая основная функция RTCP - идентификация отправителя. Пакеты RTCP содержат стандартное текстовое описание отправителя. Они предоставляют больше информации об отправителе пакетов данных, чем случайным образом выбранный идентификатор источника синхронизации. Кроме того, они помогают пользователю идентифицировать потоки, относящиеся к различным сеансам. Так, они дают пользователю возможность определить, что одновременно открыты отдельные сеансы для аудио и видео.
Третья функция состоит в оценке размеров сеанса и масштабировании. Для обеспечения качества услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправителя, все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников.
При небольшом числе участников один пакет RTCP посылается максимум каждые пять секунд. RFC 1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.
Назначение любой сети состоит в доставке данных получателем с гарантированным качеством услуг, включающих пропускную способность, задержку и допустимый предел вариации задержки. С ростом числа пользователей и приложений обеспечить качество услуг становится все труднее.
Всего лишь реагировать на перегрузку - уже недостаточно. Необходим инструмент, с помощью которого перегрузок можно было бы избежать вообще, то есть сделать так, чтобы приложения могли резервировать сетевые ресурсы в соответствии с требуемым качеством услуг.
Превентивные меры полезны как при одноадресной, так и при многоадресной передаче. При одноадресной передаче два приложения договариваются о конкретном уровне качества услуг для данного сеанса. Если сеть сильно загружена, то она может оказаться не в состоянии предоставить услуги необходимого качества. В этой ситуации приложениям придется отложить сеанс до лучших времен или попробовать снизить требования к качеству услуг, если это возможно.
Решение в данном случае состоит в резервировании одноадресными приложениями ресурсов для обеспечения требуемого уровня услуг. Тогда маршрутизаторы на предполагаемом пути выделяют ресурсы (например, место в очереди и часть емкости исходящей линии). Если маршрутизатор не имеет возможности выделить ресурсы вследствие ранее взятых на себя обязательств, то он извещает об этом приложение. При этом приложение может попытаться инициировать другой сеанс с меньшими требованиями к качеству услуг или перенести его на более поздний срок.
Многоадресная рассылка ставит гораздо более сложные задачи по резервированию ресурсов. Она ведет к генерации огромных объемов сетевого графика - в случае, например, таких приложений, как видео, или при наличии большой и рассредоточенной группы получателей. Однако трафик от источника многоадресной рассылки может быть в принципе значительно снижен.
Для этого есть два основания. Во-первых, некоторые члены группы могут не нуждаться в доставке данных от конкретного источника в определенный период времени. Так, члены одной группы могут получать информацию одновременно по двум каналам (от двух источников), но при этом получатель может быть заинтересован в приеме только одного канала.
Во-вторых, что некоторые члены группы в состоянии обрабатывать только часть передаваемой отправителем информации. Например, видеопоток может состоять из двух компонентов: один с низким качеством картинки, а другой - с высоким. Такой формат имеет ряд алгоритмов сжатия видео: они генерируют базовый компонент с картинкой низкого качества и дополнительный компонент с повышенным разрешением.
Некоторые получатели могут не иметь достаточной вычислительной мощи для обработки компонентов с высоким разрешением или быть подключены к сети через подсеть или канал, не обладающие достаточной емкостью, чтобы пропустить полный сигнал.
Резервирование ресурсов позволяет маршрутизаторам заранее определить, в состоянии ли они осуществить доставку многоадресного трафика всем получателям.
В предыдущих попытках реализации резервирования ресурсов и в принятых во frame relay и АТМ подходах необходимые ресурсы запрашивает источник потока данных. Этот метод достаточен в случае одноадресной передачи, потому что передающее приложение передает данные в определенном темпе, а необходимый уровень качества услуг заложен в схему передачи.
Однако такой подход нельзя использовать для многоадресной рассылки. У разных членов группы могут быть неодинаковые требования к ресурсам. Если исходный поток может быть разделен на подпотоки, то некоторые члены группы, вполне возможно, пожелают получать только один из них. В частности, некоторые получатели смогут обрабатывать только компонент видеосигнала низкого разрешения. Или если несколько отправителей вещают на одну группу, то получатель может выбрать только одного отправителя или некоторое их подмножество. Наконец, требования различных получателей к качеству услуг могут меняться в зависимости от оборудования вывода, мощности процессора и скорости канала.
По этой причине резервирование ресурсов получателем видится предпочтительным. Отправители могут предоставить маршрутизаторам общие характеристики трафика (например, темп передачи данных и вариабельность), но получатели должны сами определить требуемый уровень качества услуг. Маршрутизаторы затем сводят воедино запросы на выделение ресурсов на общих участках дерева распространения.
В основе RSVP лежат три концепции, касающиеся потоков данных: сеанс, спецификация потока и спецификация фильтра. Сеанс - это поток данных, идентифицируемый по адресату. Отметим, что эта концепция отличается от концепции сеанса RTP, хотя сеансы RSVP и RTP могут иметь взаимно однозначное соответствие. После резервирования маршрутизатором ресурсов для конкретного адресата он рассматривает это как начало сеанса и выделяет ресурсы на время этого сеанса.
Запрос на резервирование от конечной системы-получателя, называемый описателем потока, состоит из спецификации потока и фильтра. Спецификация потока определяет требуемое качество услуг и используется узлом для задания параметров планировщика пакетов. Маршрутизатор передает пакеты с заданным набором предпочтений, опираясь на текущую спецификацию потока.
Спецификация фильтра определяет набор пакетов, под которые запрашиваются ресурсы. Вместе с сеансом она определяет набор пакетов (или поток), для которых требуемое качество услуг должно быть обеспечено. Любые другие пакеты, направляемые этому адресату, обрабатываются постольку, поскольку сеть в состоянии это сделать.
RSVP не определяет содержания спецификации потока, он просто передает запрос. Спецификация потока обычно включает класс услуг, Rspec (R означает резерв) и Tspec (T означает трафик). Два других параметра представляют собой набор чисел. Параметр Rspec определяет требуемое качество услуг, а параметр Tspec описывает поток данных. Содержимое Rspec и Tspec прозрачно для RSVP.
В принципе, спецификация фильтра описывает произвольное подмножество пакетов одного сеанса (то есть тех пакетов, адресат которых определяется данным сеансом). Например, спецификация фильтра может определять только конкретных отправителей либо определять протоколы или пакеты, поля протокольных заголовков которых совпадают с заданными.
Рис. 3 иллюстрирует связь между сеансом, спецификацией потока и спецификацией фильтра. Каждый приходящий пакет относится по крайней мере к одному сеансу и рассматривается в соответствии с логическим потоком для этого сеанса. Если пакет не принадлежит к какому-либо сеансу, то он доставляется постольку, поскольку есть свободные ресурсы.
Основная сложность RSVP связана с многоадресной рассылкой. Пример многоадресной конфигурации приведен на рис. 6 . Эта конфигурация состоит из четырех маршрутизаторов. Канал между двумя любыми маршрутизаторами, изображаемый линией, может представлять собой как прямой канал, так и подсеть. Три хоста - Gl, G2 и G3 - входят в одну группу и получают дейтаграммы с соответствующим групповым адресом. Данные по этому адресу передаются двумя хостами - S1 и S2. Красная линия соответствует дереву маршрутизации для S1 и данной группы, а синяя линия - для S2 и данной группы. Линии со стрелками указывают направление передачи пакетов от S1 (красная) и от S2 (синяя).
Рисунок показывает, что все четыре маршрутизатора должны знать о резервировании ресурсов каждым получателем. Таким образом, запросы на выделение ресурсов распространяются в обратном направлении по дереву маршрутизации.
RSVP использует два основных типа сообщений: Resv и Path. Сообщения Resv генерируются получателями и распространяются вверх по дереву, причем каждый узел по пути объединяет и компонует пакеты от разных получателей, когда это возможно. Эти сообщения приводят к переходу маршрутизатора в состояние резервирования ресурсов для данного сеанса (группового адреса). В конце концов все объединенные сообщения Resv достигают хостов-отправителей. Основываясь на полученной информации, они задают надлежащие параметры управления графиком для первого транзитного узла.
Рис. 7 показывает поток сообщений Resv. Обратите внимание: сообщения объединяются; следовательно, только одно сообщение передается вверх по любой ветви комбинированного дерева доставки. Однако эти сообщения должны периодически рассылаться вновь для продления срока резервирования ресурсов.
Сообщение Path используется для распространения информации об обратном маршруте. Всеми современными протоколами многоадресной маршрутизации поддерживается только прямой маршрут в виде дерева распространения (вниз от отправителя). Но сообщения Resv должны передаваться в обратном направлении через все промежуточные маршрутизаторы всем хостам-отправителям.
Поскольку протокол маршрутизации не предоставляет информации об обратном маршруте, она передается RSVP в сообщениях Path. Любой хост, желающий стать отправителем, посылает сообщение Path всем членам группы. По пути каждый маршрутизатор и каждый хост-адресат переходит в состояние path, указывающее, что пакеты для этого отправителя должны пересылаться на транзитный узел, с которого данный пакет получен. Рис. 5 показывает, что пакеты Path передаются по тем же самым путям, что и пакеты данных.
Рассмотрим работу протокола RSVP. С точки зрения хоста работа протокола состоит из следующих этапов (первые два этапа в этой последовательности имеют иногда обратную очередность).
Вчерашние методы работы с большими объемами графика совершенно непригодны для современных систем. Без новых инструментов удовлетворять растущим требованиям к передаче данных в связи с ростом их объема, распространением приложений реального времени и многоадресной рассылки невозможно. RTP и RSVP обеспечивают надежный фундамент для сетей следующего поколения LAN.
В качестве примера реального применения этих протоколов можно привести модель VoIP (Voice over IP) – передачи голоса по IP-сетям, которая описана в стандарте H.232 и предусматривает передачу аудио-, видеоинформации и данных через IP-сеть. В этом случае протокол реального времени RTP используется для установления соединения, а протокол RSVP – для резервирования ресурсов сети.
