Алгоритмы мультимедиа

Обработка RTCP в трансляторах

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

Транслятор, который не модифицирует информационные пакеты, например, такой, который осуществляет связь между мультикастными и уникастными адресами, может просто переадресовывать RTCP-пакеты. Транслятор, который каким-то образом модифицирует поле данных, должен выполнить соответствующие преобразования в SR и RR-информации так, чтобы она отражала качество приема. Такие трансляторы не должны просто переадресовывать RTCP-пакеты. Вообще транслятор не должен объединять SR и RR-пакеты от различных источников, так как это ухудшит точность измерения задержки распространения, использующего поля LSR и DLSR.

Информация отправителя SR. Транслятор не генерирует своей собственной информации отправителя, а переадресует SR-пакеты, полученные из одной области и адресованные в другие области. SSRC остается неизменным, но, если необходима трансляция, информация отправителя должна быть модифицирована. Если транслятор изменяет кодировку данных, он должен изменить поле число октетов отправителя. Если он объединяет несколько информационных пакетов в один, то нужно изменить поле число пакетов отправителя. Если он изменяет частоту временных меток, нужно модифицировать поле временная метка RTP в SR-пакете.

Блоки отчетов о приеме SR/RR. Транслятор переадресует доклады о приеме, полученные из одной области сети, в другие. Заметим, что эти сообщения движутся в направлении, противоположном данным. SSRC при этом остается неизменным. Если транслятор объединяет несколько информационных пакетов в один выходной пакет и, следовательно, изменяет номер по порядку, он должен позаботиться о модификации полей потерянных пакетов и наибольший номер из числа полученных пакетов.

Транслятор не нуждается в своем собственном SSRC-идентификаторе, но может и завести такой идентификатор, чтобы посылать отчеты о том, что получено. Такие отчеты будут посылаться во все области сети, подключенные к транслятору.

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

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

APP. Трансляторы переадресовывают APP-пакеты без каких-либо изменений.

Обработка RTCP в смесителях

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

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

Блоки отчетов о приеме SR/RR. Смеситель генерирует свои собственные отчеты о приеме для каждой из сетевых областей и посылает их туда. Он не посылает эти отчеты о приеме другим областям и не переадресует отчеты из одной области в другую.

SDES. Смесители обычно переадресуют без изменений SDES-информацию, которую они получают из сетевых областей зоны обслуживания, но могут в случае ограничения полосы пропускания отфильтровывать любую SDES-информацию помимо CNAME. CNAME должны доставляться, чтобы обеспечить работу по обслуживанию столкновений идентификаторов SSRC. Идентификатор в списке CSRC, сгенерированный смесителем, может вызвать столкновение с SSRC-идентификатором, сформированным оконечной системой. Смеситель должен послать SDES CNAME информацию о самом себе той сетевой области, куда он посылает SR или RR пакеты.

Так как смесители не переадресуют SR- или RR-пакеты, они обычно извлекают SDES-пакеты из составных RTCP-пакетов. Для того, чтобы минимизировать издержки, фрагменты из SDES-пакетов могут быть уложены в один SDES-пакет, который вкладывается в SR- или RR-пакет, посылаемый смесителем.

Смеситель, который не вводит идентификаторы CSRC, может также воздерживаться от пересылки SDES CNAME. В этом случае пространства идентификаторов SSRC для обеих сетевых областей оказываются независимыми.

BYE. Смесители должны переадресовывать пакеты BYE. Они должны генерировать пакеты BYE со своим собственным идентификатором SSRC, если они намериваются прервать пересылку пакетов.

APP. Обработка APP-пакетов смесителями зависит от вида приложения.

Эти значения типов были выбраны в диапазоне 200-204 для улучшенного контроля корректности заголовков RTCP пакетов. Когда поле типа пакета RTCP сравнивается с соответствующим октетом RTP-заголовка, этот диапазон соответствует маркерному биту 1 (который обычно отсутствует в информационных пакетах) и старшему биту стандартного поля типа данных, равному 1 (так как статические типы поля данных обычно лежат в младшей половине).

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

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

Период отчетов RTCP. Профайл должен специфицировать, какие значения констант будут использоваться для вычисления периода посылки RTCP докладов. Этот период определяет долю полосы пропускания выделенной для RTCP.

Расширения SR/RR. Секция расширения может быть определена для RTCP SR- и RR-пакетов, если имеется дополнительная информация о получателе или отправителе, которая должна регулярно передаваться.

Проверка корректности заголовка RTCP

Пакеты RTCP подвергаются следующим проверкам.

• RTP поле версии должно быть равно 2.
• Поле типа данных первого RTCP пакета в составном пакете должно быть SR или RR.
• Бит заполнителя (P) должен быть равен нулю для первого пакета составного RTCP-пакета, так как заполнитель может присутствовать только в последнем.
• Длина полей индивидуальных RTCP-пакетов должна в сумме равняться полной длине составного пакета.

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

Протокол RSVP (L. Zhang, R. Braden, Ed., S. Berson, S. Herzog, S. Jamin "Resource ReSerVation Protocol", RFC-2205, 2210, 274547, 3182, смотри также http://book.itep.ru/ 4\44\rsv_4496.htm) используется ЭВМ для того, чтобы запросить для приложения определенный уровень качества сетевых услуг QoS (Quality of Service, например, определенный уровень полосы пропускания). RSVP применяется также маршрутизаторами для доставки QoS-запросов всем узлам вдоль пути информационного потока, а также для установки и поддержания необходимого уровня услуг (например, для приложений IP-телефонии). Функция этого протокола крайне важна и многообразна, и именно поэтому он — один из самых сложных протоколов.

Протокол RSVP обеспечивает интегрированный стиль резервирования сетевых ресурсов (IntServ).

В 1994 году группа IETF сформировала рабочую группу по интегрированным услугам (Intserv Working Group). Целью группы было расширение спектра услуг Интернет. Интегрированные услуги предполагают сигнальный механизм информирования вовлеченных сетевых устройств о необходимом качестве обслуживания. RSVP стал сигнальным протоколом для архитектуры IntServ. Хотя первоначально RSVP был предназначен для мультимедийных систем, этот протокол может успешно использоваться и для таких сетевых систем, как NFS или VPN.

RSVP запрашивает ресурсы только для одного из направлений трафика и только по указанию получателя. RSVP работает поверх IPv4 или IPv6. Протокол относится к числу управляющих, а не транспортных.

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

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

Структура и содержимое параметров QoS документировано в спецификации RFC-2210. Так как число участников группы, а также топология связей меняется со временем, структура RSVP предполагает адаптацию ЭВМ и маршрутизаторов к этим изменениям. Для этой цели RSVP периодически посылает сообщения для поддержания необходимого состояния вдоль всего маршрута обмена. При отсутствии этих сообщений происходит тайм-аут, и резервирование аннулируется. Обобщая, можно сказать, что RSVP имеет следующие атрибуты:

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

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

Рис. 10.23. RSVP в ЭВМ и маршрутизаторе

Потоки данных

RSVP определяет сессию как поток данных с определенным местом назначения и заданным транспортным протоколом. Каждая сессия является совершенно независимой.

Сессия RSVP описывается тремя параметрами: DestAddress, ProtocolId DstPort. DestAddress — IP-адрес места назначения информационных пакетов (уникаст или мультикаст). ProtocolId — идентификатор IP протокола. Опционный параметр DstPort — обобщенный порт места назначения, т.е. еще одна точка демультиплексирования на транспортном или прикладном уровне. DstPort может быть определено полем порта места назначения UDP/TCP.

Заметим, что, строго говоря, не обязательно включать в описание сессии DstPort, когда DestAddress является мультикастным, так как различные сессии могут иметь различные мультикаст-адреса. Однако, DstPort необходим, чтобы разрешить более одной уникаст-сессии для одной и той же ЭВМ-получателя.

Для уникастной передачи может быть один получатель, но много отправителей; RSVP может выполнить резервирование для передачи много_точек -> одна_точка.