Добрый день!
Итого: система мониторинга представляет собой комплекс, подключаемый в неинтрузивном режиме к n-ному количеству 10-гигабитных линков Ethernet, который непрерывно “наблюдает” за передачей всех присутствующих в трафике видео-потоков RTP и проводит измерения с определённым интервалом времени, чтобы потом сохранить их в базу. По данным из базы регулярно строятся отчёты для всех камер.
В процессе поиска решения сразу зафиксировали несколько проблем:
Мы, естественно, стремились максимально использовать собственный опыт. К моменту принятия решения у нас уже была реализация обработки ethernet-пакетов на FPGA-powered девайсе Беркут-МХ (проще - MX). С помощью Беркут-MX мы умели получать из заголовков Ethernet-пакетов нужные поля для анализа. Опыта обработки такого объёма трафика средствами “обычных” серверов у нас не было, увы, поэтому на подобное решение смотрели с некоторой опаской…
Казалось бы, оставалось просто применить метод к RTP-пакетам и золотой ключик был бы у нас в кармане, но MX умеет только обрабатывать трафик, в него не заложены возможности учёта и хранения статистики. Для хранения найденных соединений (комбинаций IP-IP-порт-порт) в ПЛИС не хватит памяти, ведь в 2x10-гигабитном линке, заходящем на вход, может быть около 15 тысяч видео-потоков, и по каждому нужно “помнить” количество принятых пакетов, количество потерянных пакетов и так далее… Более того, поиск на такой скорости и по такому количеству данных при условии обработки без потерь становится нетривиальной задачей.
Чтобы найти решение, пришлось “копнуть глубже” и разобраться в том, по каким алгоритмам мы будем измерять качество и идентифицировать видео-потоки.
Из описания видно, что с точки зрения измерений качества в RTP-пакете нас интересуют следующие поля:
Вполне очевидно, что sequence number позволяет определить следующие параметры потока:
Timestamp позволяет измерить:
Ну а M-бит позволяет измерить частоту кадров. Правда, SPS/PPS-кадры протокола h.264 вносят погрешность, т.к. видео-кадрами не являются. Но её можно нивелировать, использовав информацию из заголовка NAL-unit’а, который всегда идёт следом за RTP-заголовком.
Подробные алгоритмы измерения параметров выходят за рамки статьи, не буду заглубляться. Если интересно, то в rfc3550 есть пример кода вычисления потерь и формулы для вычисления джиттера . Главный же вывод заключается в том, что для измерений базовых характеристик транспортного потока достаточно всего лишь нескольких полей из RTP-пакетов и NAL-юнитов. А остальная информация в измерениях не участвует и её можно и нужно отбросить!
Для ведения статистики информацию, полученную из RTP-заголовка, необходимо “привязать” к некоторому идентификатору камеры (видео-потока). Камеру можно однозначно идентифицировать по следующим параметрам:
Что интересно, мы сначала сделали идентификацию камер только по IP источника и SSRC, полагаясь на то, что SSRC должен быть случайным, но на практике оказалось, что многие камеры устанавливают SSRC в фиксированное значение (скажем, 256). Видимо, это связано с экономией ресурсов. В итоге нам пришлось к идентификатору камеры добавить ещё и порты. Это решило проблему уникальности полностью.
Остался вопрос: как Беркут-MX, приняв пакет, поймёт, что это RTP? RTP-заголовок не имеет такой явной идентификации, как IP, у него нет контрольной суммы, передаваться он может по UDP с номерами портов, которые выбираются динамически при установке соединения. А в нашем случае большинство соединений уже давно установлены и ждать переустановки можно очень долго.
Для решения этой задачи в rfc3550 (Appendix A.1) рекомендуется проверять биты версии RTP - это два бита, и поле Payload Type (PT) - семь бит, которое в случае с динамическим типом принимает небольшой диапазон. Мы на практике выяснили, что для того множества камер, c которым мы работаем, PT укладывается в диапазон от 96 до 100.
Есть ещё один фактор - чётность порта, но как показала практика, не всегда соблюдается, поэтому от него пришлось отказаться.
Таким образом, поведение Беркут-MX следующее:
Очевидно, что при таком подходе есть ложноположительные срабатывания, т.к. под такие простые критерии могут попадать не только RTP-пакеты. Но для нас важно, что RTP-пакет мы точно не пропустим, а «неправильные» пакеты отфильтрует уже сервер.
Для фильтрации ложных случаев сервер использует механизм, который регистрирует источник видео-трафика по нескольким последовательно принятым пакетам (в пакете же есть sequence number!). Если несколько пакетов пришло с последовательными номерами, то это не случайное совпадение и начинаем работать с этим потоком. Этот алгоритм оказался весьма надёжным.
Поняв, что вся информация, идущая в пакетах, для измерения качества и идентификации потоков не нужна, мы решили всю highload & time-critical работу по приёму и вычленению полей RTP-пакетов взвалить на Беркут-MX, то бишь на FPGA. Он “находит” видео-поток, разбирает пакет, оставляет только нужные поля и в UDP-туннеле отправляет на обычный сервер. Сервер проводит измерения по каждой камере и сохраняет результаты в базу данных.
В итоге сервер работает не с 50-60 Гигабит/с, а максимум с 5% (именно такая получилась пропорция отсылаемых данных к среднему размеру пакета). То есть на входе всей системы 55 Гигабит/с, а на сервер попадает всего-то не более 3 Гигабит/с!
В итоге у нас получилась такая архитектура:
И первый результат в такой конфигурации мы получили через две недели после постановки начального ТЗ!
Итак, что же делает сервер в нашей архитектуре? Его задачи:
При том, что суммарный трафик на входе сервера составляет около 3 Гигабит/с, сервер справляется даже при условии, что мы не используем никаких DPDK, а работаем просто через linux’овый сокет (предварительно увеличив размер буфера для сокета, конечно). Более того, можно будет подключать новые линки и MX"ы, потому что запас по производительности остаётся.
Вот как выглядит top сервера (это top только одного lxc-контейнера, отчёты генерируются в другом):
Из него видно, что вся нагрузка по расчёту параметров качества и учёту статистики распределена по четырём процессам равномерно. Нам удалось добиться такого распределения за счёт применения хеширования в FPGA: по IP считается хеш-функция, а младшие биты полученного хеша определяют номер UDP-порта, на который уйдёт статистика. Соответственно, каждый процесс, слушающий свой порт, получает примерно одинаковое количество трафика.
Настало время похвастаться и признаться в недостатках полученного решения.
Начну с плюсов:
Справедливости ради рассмотрю и недостатки:
В конечном итоге у нас получился программно-аппаратный комплекс, в котором мы можем контролировать и ту часть, которая парсит пакеты на интерфейсах, и ту, которая ведёт статистику. Полный контроль над всеми узлами системы буквально спас нас, когда камеры начали переводить на RTSP/TCP interleaved mode. Потому что в этом случае заголовок RTP перестал располагаться в пакете по фиксированному смещению: он может находиться где угодно, даже на границе двух пакетов (первая половина в одном, вторая - в другом). Соответственно, алгоритм получения RTP-заголовка и его полей претерпел кардинальные изменения. Нам пришлось сделать TCP reassembling на сервере для всех 50000 соединений - отсюда и довольно высокая нагрузка в top’е.
Мы никогда до этого не работали в сфере высоконагруженных приложений, но нам удалось решить задачу за счёт наших скилов в FPGA и получилось довольно-таки неплохо. Даже остался запас - например, к системе с 55000 камерами можно подключить ещё 20-30 тысяч потоков.
Тюнинг linux’овых подсистем (распределение очередей по прерываниям, увеличение приёмных буферов, директивное выделение ядер на конкретные процессы и т.п.) я оставил за рамками статьи, т.к. эта тема и так уже очень хорошо освещена.
Я описал далеко не всё, граблей было собрано немало, поэтому не стесняйтесь задавать вопросы:)
Большое спасибо всем, кто дочитал до конца!
Самой насущной проблемой все чаще становится нехватка адресного пространства, что требует изменения формата адреса.
Другой проблемой является недостаточная масштабируемость процедуры маршрутизации - основы IP-сетей. Быстрый рост сети вызывает перегрузку маршрутизаторов, которые уже сегодня вынуждены поддерживать таблицы маршрутизации с десятками и сотнями тысяч записей, а также решать проблемы фрагментации пакетов. Облегчить работу маршрутизаторов можно, в частности, путем модернизации протокола IP.
Наряду с вводом новых функций непосредственно в протокол IP, целесообразно обеспечить более тесное взаимодействие его с новыми протоколами путем введения в заголовок пакета новых полей.
В результате было решено подвергнуть протокол IP модернизации, преследуя следующие основные цели:
Расширение адресного пространства . Протокол IP решает потенциальную проблему нехватки адресов за счет расширения разрядности адреса до 128. Однако такое существенное увеличение длины адреса было сделано в значительной степени не с целью снять проблему дефицита адресов, а для повышения эффективности работы сетей на основе этого протокола. Главной целью было структурное изменение системы адресации, расширение ее функциональных возможностей.
Вместо существующих двух уровней иерархии адреса (номер сети и номер узла) в протоколе IPv6 предлагается использовать четыре уровня, что предполагает трехуровневую идентификацию сетей и один уровень для идентификации узлов.
Теперь адрес записывается в шестнадцатеричном виде, причем каждые четыре цифры отделяются друг от друга двоеточием, например:
FEDC:0A96:0:0:0:0:7733:567A.
Для сетей, поддерживающих обе версии протокола IPv4 и IPv6 , имеется возможность использовать для младших 4 байтов традиционную десятичную запись, а для старших - шестнадцатеричную:
0:0:0:0:FFFF 194.135.75.104.
В рамках системы адресации IPv6 имеется также выделенное пространство адресов для локального использования, то есть для сетей, не входящих в Интернет. Существует две разновидности локальных адресов : для "плоских" сетей, не разделенных на подсети (Link-Local), и для сетей, разделенных на подсети (Site-Local), которые различаются значением префикса.
Изменение формата заголовков пакетов. Реализовать это позволяет новая схема организации "вложенных заголовков", обеспечивающая разделение заголовка на основной, который содержит необходимый минимум информации, и дополнительные, которые могут отсутствовать. Такой подход открывает богатые возможности для расширения протокола путем определения новых опциональных заголовков, делая протокол открытым.
Основной заголовок дейтаграммы IPv6 длиной 40 байтов имеет следующий формат ( рис. 2.4).
Поле Класс трафика ( Traffic Class) эквивалентно по назначению полю Тип обслуживания (Type Of Service) , а поле Лимит переходов ( Hop Limit) - полю Время жизни (Time To Live) протокола IPv4.
Поле Метка потока (Flow Label) позволяет выделять и особым образом обрабатывать отдельные потоки данных без необходимости анализировать содержимое пакетов. Это очень важно с точки зрения снижения нагрузки на маршрутизаторы.
Поле Следующий заголовок (Next Header) является аналогом поля Протокол (Protocol) IPv4 и определяет тип заголовка, следующего за основным. Каждый следующий дополнительный заголовок также содержит поле Next Header .
Протокол управления передачей информации (Transmission Control Protocol - TCP) был разработан для поддержки интерактивной связи между компьютерами. Протокол TCP обеспечивает надежность и достоверность обмена данными между процессами на компьютерах, входящих в общую сеть.
К сожалению, протокол TCP не приспособлен для передачи мультимедийной информации. Основная причина - наличие контроля за доставкой. Контроль отнимает слишком много времени для передачи более чувствительной к задержкам информации. Кроме того, TCP предусматривает механизмы управления скоростью передачи с целью избежать перегрузок сети. Аудио- и видеоданные требуют, однако, строго определенных скоростей передачи, которые нельзя изменять произвольным образом.
С одной стороны протокол TCP взаимодействует с прикладным протоколом пользовательского приложения, а с другой - с протоколом, обеспечивающим "низкоуровневые" функции маршрутизации и адресации пакетов, которые, как правило, выполняет IP.
Логическая структура сетевого программного обеспечения, реализующего протоколы семейства TCP/IP в каждом узле сети Интернет, изображена на рис. 2.5 .
Прямоугольники обозначают модули, обрабатывающие данные, а линии, соединяющие прямоугольники, - пути передачи данных. Горизонтальная линия внизу рисунка обозначает сеть Ethernet, которая используется в качестве примера физической среды.
Рис.
2.5.
Чтобы установить соединение между двумя процессами на разных компьютерах сети, необходимо знать не только интернет-адреса компьютеров, но и номера тех ТСР-портов (sockets), которые процессы используют на этих компьютерах. Любое TCP-соединение в сети Интернет однозначно идентифицируется двумя IP-адресами и двумя номерами ТСР-портов.
Протокол TCP умеет работать с поврежденными, потерянными, дублированными или поступившими с нарушением порядка следования пакетами. Это достигается благодаря механизму присвоения каждому передаваемому пакету порядкового номера и механизму проверки получения пакетов.
Когда протокол TCP передает сегмент данных, копия этих данных помещается в очередь повтора передачи и запускается таймер ожидания подтверждения.
Протокол передачи пользовательских дейтаграмм (User Datagram Protocol - UDP) предназначается для обмена дейтаграммами между процессами компьютеров, расположенных в объединенной системе компьютерных сетей.
Протокол UDP базируется на протоколе IP и предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает негарантированную доставку данных, т. е. не требует подтверждения их получения; кроме того, данный протокол не требует установления соединения между источником и приемником информации, т. е. между модулями UDP.
Транспортный протокол реального времени RTP обеспечивает сквозную передачу в реальном времени мультимедийных данных, таких как интерактивное аудио и видео. Этот протокол реализует распознавание типа трафика, нумерацию последовательности пакетов, работу с метками времени и контроль передачи.
Действие протокола RTP сводится к присваиванию каждому исходящему пакету временных меток. На приемной стороне временные метки пакетов указывают на то, в какой последовательности и с какими задержками их необходимо воспроизводить. Поддержка RTP и RTCP позволяет принимающему узлу располагать принимаемые пакеты в надлежащем порядке, снижать влияние неравномерности времени задержки пакетов в сети на качество сигнала и восстанавливать синхронизацию между аудио и видео, чтобы поступающая информация могла правильно прослушиваться и просматриваться пользователями.
Заметим, что RTP сам по себе не имеет никакого механизма, гарантирующего своевременную передачу данных и качество обслуживания , но для обеспечения этого использует службы нижележащего уровня. Он не предотвращает нарушения порядка следования пакетов, но при этом и не предполагает, что основная сеть абсолютно надежна и передает пакеты в нужной последовательности. Порядковые номера, включенные в RTP , позволяют получателю восстанавливать последовательность пакетов отправителя.
Протокол RTP поддерживает как двустороннюю связь, так и передачу данных группе адресатов, если групповая передача поддерживается нижележащей сетью. RTP предназначен для обеспечения информации, требуемой отдельным приложениям, и в большинстве случаев интегрируется в работу приложения.
Хотя протокол RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol). Оба протокола вносят свои доли в функциональность транспортного уровня. Следует отметить, что RTP и RTCP являются независимыми от нижележащих уровней - транспортного и сетевого, поэтому протоколы RTP / RTCP могут использоваться с другими подходящими транспортными протоколами.
Протокольные блоки данных RTP / RTCP называются пакетами. Пакеты, формируемые в соответствии с протоколом RTP и служащие для передачи мультимедийных данных, называются информационными пакетами или пакетами данных ( data packets ), а пакеты, генерируемые в соответствии с протоколом RTCP и служащие для передачи служебной информации, которая требуется для надежной работы телеконференции , называют пакетами управления или служебными пакетами ( control packets ). Пакет RTP включает в свой состав фиксированный заголовок, необязательное расширение заголовка переменной длины и поле данных. Пакет RTCP начинается с фиксированной части (подобной фиксированной части информационных пакетов RTP ), за которой следуют структурные элементы, имеющие переменную длину.
Для того, чтобы протокол RTP был более гибким и мог применяться для различных приложений, некоторые его параметры сделаны преднамеренно неопределенными, но зато в нем предусмотрено понятие профиля. Профиль (profile) - это набор параметров протоколов RTP и RTCP для конкретного класса приложений, определяющий особенности их функционирования. В профиле определяются: использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги и алгоритмы обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т. д. Каждое приложение обычно работает только с одним профилем, и задание типа профиля происходит путем выбора соответствующего приложения. Никакой явной индикации типа профиля номером порта, идентификатором протокола и т. п. не предусмотрено.
Таким образом, полная спецификация RTP для конкретного приложения должна включать дополнительные документы, к которым относятся описание профиля, а также описание формата трафика, определяющее, как трафик конкретного типа, такой как аудио или видео, будет обрабатываться в RTP .
Для организации групповой аудио-конференц-связи требуется многопользовательский групповой адрес и два порта. При этом один порт необходим для обмена звуковыми данными, а другой используется для пакетов управления протокола RTCP . Информация о групповом адресе и портах передается предполагаемым участникам телеконференции . Если требуется секретность, то информационные и управляющие пакеты могут быть зашифрованы, в этом случае также должен быть сгенерирован и распределен ключ шифрования.
Приложение аудио-конференц-связи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например, продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP ; заголовок RTP и данные поочередно формируются (инкапсулируются) в пакет UDP. Заголовок RTP показывает, какой тип кодирования звука (например, ИКМ, АДИКМ или LPC ) применялся при формировании данных в пакете. Это дает возможность изменять тип кодирования в процессе конференции, например, при появлении нового участника, который использует линию связи с низкой полосой пропускания, или при перегрузках сети.
В сети Интернет, как и в других сетях передачи данных с коммутацией пакетов, пакеты иногда теряются и переупорядочиваются, а также задерживаются на различное время. Для противодействия этим событиям заголовок RTP содержит временную метку и порядковый номер, которые позволяют получателям восстановить синхронизацию в исходном виде так, чтобы, например, участки звукового сигнала воспроизводились динамиком непрерывно каждые 20 мс. Эта реконструкция синхронизации выполняется отдельно и независимо для каждого источника пакетов RTP в телеконференции . Порядковый номер может также использоваться получателем для оценки количества потерянных пакетов.
Так как участники телеконференции могут вступать и выходить из нее во время ее проведения, то полезно знать, кто участвует в ней в данный момент и насколько хорошо участники конференции получают звуковые данные. Для этой цели каждый экземпляр звукового приложения во время конференции периодически выдает на порт управления (порт RTCP ) для приложений всех остальных участников сообщения о приеме пакетов с указанием имени своего пользователя. Сообщение о приеме указывает, как хорошо слышим текущий оратор, и может использоваться для управления адаптивными кодерами . В дополнение к имени пользователя может быть включена также другая информация идентификации для контроля полосы пропускания. При выходе из конференции сайт посылает пакет BYE протокола RTCP .
Если в телеконференции используются и звуковые, и видеосигналы, то они передаются отдельно. Для передачи каждого типа трафика независимо от другого спецификацией протокола вводится понятие сеанса связи RTP . Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP ). Пакеты для каждого типа трафика передаются с использованием двух различных пар портов UDP и/или групповых адресов. Никакого непосредственного соединения на уровне RTP между аудио- и видеосеансами связи не имеется, за исключением того, что пользователь, участвующий в обоих сеансах, должен использовать одно и то же каноническое имя в RTCP -пакетах для обоих сеансов, чтобы сеансы могли быть связаны.
Одна из причин такого разделения состоит в том, что некоторым участникам конференции необходимо позволить получать только один тип трафика, если они этого желают. Несмотря на разделение, синхронное воспроизведение мультимедийных данных источника (звука и видео) может быть достигнуто при использовании информации таймирования, которая переносится в пакетах RTCP для обоих сеансов.
Не всегда все сайты имеют возможность получать мультимедийные данные в одинаковом формате. Рассмотрим случай, когда участники из одной местности соединены через низкоскоростную линию связи с большинством других участников конференции, которые обладают широкополосным доступом к сети. Вместо того чтобы вынуждать каждого использовать более узкую полосу пропускания и звуковое кодирование с пониженным качеством, средство связи уровня RTP , называемое микшером, может быть размещено в области с узкой полосой пропускания. Этот микшер повторно синхронизирует входящие звуковые пакеты для восстановления исходных 20-миллисекундных интервалов, микширует эти восстановленные звуковые потоки в один поток, производит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи. При этом пакеты могут быть адресованы одному получателю или группе получателей с различными адресами. Чтобы в приемных оконечных точках можно было обеспечивать правильную индикацию источника сообщений , заголовок RTP включает для микшеров средства опознавания источников, участвовавших в формировании смешанного пакета.
Некоторые из участников аудиоконференции могут быть соединены широкополосными линиями связи, но могут быть недостижимы посредством групповой конференц-связи с использованием протокола IP ( IPM - IP multicast ). Например, они могут находиться за брандмауэром прикладного уровня, который не будет допускать никакой передачи IP-пакетов. Для таких случаев нужны не микшеры, а средства связи уровня RTP другого типа, называемые трансляторами. Из двух трансляторов один устанавливается вне брандмауэра и снаружи передает все групповые пакеты, полученные через безопасное соединение, другому транслятору, установленному за брандмауэром. Транслятор за брандмауэром передает их снова как мультивещательные пакеты многопользовательской группе, ограниченной внутренней сетью сайта.
Микшеры и трансляторы могут быть разработаны для ряда целей. Пример: микшер видеосигнала, который масштабирует видеоизображения отдельных людей в независимых потоках видеосигнала и выполняет их композицию в один поток видеосигнала, моделируя групповую сцену.
Все поля пакетов RTP / RTCP передаются по сети байтами (октетами); при этом наиболее значащий байт передается первым. Все данные полей заголовка выравниваются в соответствии с их длиной. Октеты , обозначенные как дополнительные, имеют нулевое значение.
Протокол управления RTСP ( RTCP - Real-Time Control Protocol) основан на периодической передаче пакетов управления всем участникам сеанса связи при использовании того же механизма распределения, что и протокол RTP . Протокол нижележащего уровня должен обеспечить мультиплексирование информационных и управляющих пакетов, например, с использованием различных номеров портов UDP. Протокол RTCP выполняет четыре основные функции.
Функции с первой по третью являются обязательными, когда RTP используется в IP-мультивещании, и рекомендуемыми во всех остальных случаях. Разработчикам приложений RTP предлагается избегать механизмов, работающих только в двустороннем режиме и не масштабируемых для увеличения числа пользователей.
Протокол RTP позволяет приложению автоматически масштабировать представительность сеанса связи в пределах от нескольких участников до нескольких тысяч. Например, в аудиоконференции трафик данных, по существу, является самоограничивающим, потому что только один или два человека могут говорить одновременно, и при групповом распределении скорость передачи данных на любой линии связи остается относительно постоянной, не зависящей от числа участников. Однако трафик управления самоограничивающим не является. Если отчеты приема от каждого участника посылаются с постоянной интенсивностью, то трафик управления с ростом числа участников будет расти линейно. Следовательно, должен быть предусмотрен специальный механизм понижения частоты передачи управляющих пакетов.
Для каждого сеанса предполагается, что трафик данных соответствует агрегированному пределу, называемому полосой пропускания сеанса связи, которая совместно используется всеми участниками. Эта полоса пропускания может быть зарезервирована, и ее предел установлен сетью. Полоса пропускания сеанса не зависит от типа кодирования мультимедийных данных, но выбор типа кодирования может быть ограничен полосой пропускания сеанса связи. Параметр полосы пропускания сеанса, как ожидается, будет обеспечен приложением управления сеанса, когда оно вызовет мультимедийное приложение, но мультимедийные приложения могут также устанавливать значение по умолчанию, основанное на полосе пропускания данных с единственным отправителем для типа кодирования, выбранного для данного сеанса.
Вычисления полосы пропускания для трафика управления и данных выполняются с учетом нижележащих протоколов транспортного и сетевого уровней (например, UDP и IP). Заголовки уровня звена передачи данных (ЗПД) при вычислениях не учитываются, так как пакет по мере его передачи может инкапсулироваться с различными заголовками уровня ЗПД.
Трафик управления должен быть ограничен малой и известной частью полосы пропускания сеанса: малой настолько, чтобы не пострадала основная функция транспортного протокола - передача данных; известной так, чтобы трафик управления мог быть включен в спецификацию полосы пропускания, данную протоколу резервирования ресурсов , и так, чтобы каждый участник мог независимо вычислить свою долю. Предполагается, что часть полосы пропускания сеанса, выделяемая для RTCP , должна быть установлена равной 5 %. Все участники сеанса должны использовать одинаковую величину полосы пропускания RTCP , так, чтобы вычисленные значения интервала передачи пакетов управления были одинаковыми. Поэтому эти константы должны быть установлены для каждого профиля.
Алгоритм вычисления интервала между посылками составных пакетов RTCP для разделения среди участников полосы пропускания, выделенной для трафика управления, имеет следующие основные характеристики:
В одном блоке данных протокола нижележащего уровня, например, в пакете UDP, могут передаваться несколько пакетов протокола RTP . Это позволяет уменьшить избыточность заголовков и упростить синхронизацию между различными потоками.
Если в один прекрасный день вам придется на скорую руку разобраться, что есть VoIP (voice over IP) и что значат все эти дикие аббревиатуры, надеюсь, эта методичка поможет. Сразу замечу, что вопросы конфигурирования дополнительных видов обслуживания телефонии (такие как перевод вызова, голосовая почта, конференц-связь и т.п.) здесь не рассматриваются.
Итак, с чем мы будем разбираться под катом:
В общем виде схема подключения локального абонента к телефонному провайдеру по обычной телефонной линии выглядит следующим образом:
На стороне провайдера (АТС) установлен телефонный модуль с портом FXS (Foreign eXchange Subscriber). Дома или в офисе установлен телефон или факс с портом FXO (Foreign eXchange Office) и модуль номеронабирателя.
По внешнему виду порты FXS и FXO никак не отличаются, это обычные 6-выводные RJ11-разъемы. Но с помощью вольтметра отличить их очень просто - на FXS-порте всегда будет какое-то напряжение: 48/60 В, когда трубка положена, или 6–15 В во время разговора. На FXO, если он не подключен к линии, напряжение всегда 0.
Для передачи данных по телефонной линии на стороне провайдера нужна дополнительная логика, которую можно реализовать на модуле SLIC (subscriber line interface circuit), а на стороне абонента - с помощью модуля DAA (Direct Access Arrangement).
Сейчас довольно популярны беспроводные DECT-телефоны (Digital European Cordless Telecommunications). По устройству они аналогичны обычным телефонным аппаратам: в них тоже есть FXO-порт и модуль номеронабирателя, но еще добавлен модуль беспроводной связи станции и трубки на частоте 1,9 ГГц.
Абоненты подключаются к PSTN-сети (Public Switched Telephone Network) - телефонной сети общего пользования, она же ТСОП, ТфОП. PSTN-сеть может быть организована с использованием разных технологий: ISDN, оптики, POTS, Ethernet. Частный случай PSTN, когда используется обычная аналоговая/медная линия - POTS (Plain Old Telephone Service) - простая старая телефонная система.
С развитием Интернета телефонная связь перешла на новый уровень. Стационарные телефонные аппараты все реже используются, в основном по служебным нуждам. DECT-телефоны немного удобнее, но ограничены периметром дома. GSM-телефоны еще удобнее, но ограничены пределами страны (роуминг - дело дорогое). А вот для IP-телефонов, они же cофтфоны (SoftPhone), никаких ограничений, кроме доступа к интернету, нет.
Skype - самый известный пример софтфона. Он может много чего, но имеет два важных недостатка: закрытая архитектура и прослушка известно какими органами. Из-за первого нет возможности создать свою телефонную микросеть. А из-за второго - не очень приятно, когда за вами подсматривают, особенно при личных и коммерческих разговорах.
К счастью есть открытые протоколы для создания своих коммуникационных сетей с плюшками - это SIP и H.323. Софтфонов на SIP-протоколе несколько больше чем на H.323, что можно объяснить его сравнительной простотой и гибкостью. Но иногда эта гибкость может вставлять большие палки в колёса. Оба протокола SIP и H.323 используют RTP-протокол для передачи медиаданных.
Рассмотрим базовые принципы протокола SIP, чтобы разобраться, как происходит соединения двух абонентов.
SIP (Session Initiation Protocol) - протокол установления сессии (не только телефонной) - это текстовый протокол поверх UDP. Также есть возможность использовать SIP поверх TCP, но это редкие случаи.
SDP (Session Description Protocol) - протокол согласования типа передаваемых данных (для звука и видео это кодеки и их форматы, для факсов - скорость передачи и коррекция ошибок) и адреса их назначения (IP и порт). Это также текстовый протокол. Параметры SDP передаются в теле SIP-пакетов.
RTP (Real-time Transport Protocol) - протокол передачи аудио/видеоданных. Это бинарный протокол поверх UDP.
Общая структура SIP-пакетов:
Вот пример двух SIP-пакетов для одной частой процедуры - установления вызова:
Слева изображено содержимое пакета SIP INVITE, справа - ответ на него - SIP 200 OK.
Основные поля выделены рамками:
SDP-сообщение состоит из строк, содержащих пары ПОЛЕ=ЗНАЧЕНИЕ. Из основных полей можно отметить:
RTP-пакеты содержат аудио/видеоданные, закодированные в определенном формате. Данный формат указывается в поле PT (payload type). Таблица соответствия значения данного поля конкретному формату приведена в https :// wikipedia org wiki RTP audio video profile .
Также в RTP-пакетах указывается уникальный SSRC-идентификатор (определяет источник RTP-потока) и метка времени (timestamp, используется для равномерного проигрывания звука или видео).
Пример взаимодействия двух SIP-абонентов через SIP-сервер (Asterisk):
Как только запускается SIP-телефон, первым делом он регистрируется на удаленном сервере (SIP Registar), отправляет ему сообщение SIP REGISTER.
При вызове абонента отправляется сообщение SIP INVITE, в теле которого вложено SDP-сообщение, в котором указываются параметры передачи звука/видео (какие кодеки поддерживаются, на какой IP и порт отправлять звук и др.).
Когда удаленный абонент поднимает трубку, нам приходит сообщение SIP 200 OK также с параметрами SDP, только удаленного абонента. Используя отправленные и полученные SDP-параметры можно устанавливать RTP-сессию передачи звука/видео или T.38-сессию передачи факсов.
Если полученные параметры SDP нас не устроили, или промежуточный SIP-сервер решил не пропускать через себя RTP-трафик, то выполняется процедура повторного согласования SDP, так называемый REINVITE. Кстати, именно из-за этой процедуры у бесплатных SIP-прокси-серверов есть один недостаток - если оба абонента находятся в одной локальной сети, а прокси-сервер находится за NAT"ом, то после перенаправления RTP-трафика ни один из абонентов не будет слышать другого.
После окончания разговора, абонент положивший трубку, отправляет сообщение SIP BYE.
Иногда после установления сессии, во время разговора, требуется доступ к дополнительным видам обслуживания (ДВО) - удержание вызова, перевод, голосовая почта и т.п. - которые реагируют на определенные сочетания нажатых кнопок.
Так, в обычной телефонной линии есть два способа набора номера:
Во время разговора импульсный способ неудобен для передачи нажатой кнопки. Так, на передачу «0» требуется приблизительно 1 секунда (10 импульсов по 100 мс: 60 мс - разрыв линии, 40 мс - замыкание линии) плюс 200 мс на паузу между цифрами. К тому же во время импульсного набора будут часто слышны характерные щелчки. Поэтому в обычной телефонии используется только тоновый режим доступа к ДВО.
В VoIP-телефонии информация о нажатых кнопках может передаваться тремя способами:
Передача DTMF внутри аудиоданных(Inband) имеет несколько недостатков - это накладные ресурсы при генерации/встраивании тонов и при их детектировании, ограничения некоторых кодеков, которые могут исказить DTMF-коды, и слабая надежность при передаче (если потеряется часть пакетов, то может произойти детектирование двойного нажатия одной и той же клавиши).
Главное различие между DTMF RFC2833 и SIP INFO: если на SIP-прокси-сервере включена возможность передачи RTP непосредственно между абонентами минуя сам сервер (например, canreinvite=yes в asterisk), то сервер не заметит RFC2833-пакеты, вследствие чего становятся недоступными сервисы ДВО. Передача SIP-пакетов всегда осуществляется через SIP-прокси-серверы, поэтому ДВО всегда будут работать.
Как уже упоминалось, для передачи медиаданных используются RTP-протокол. В RTP-пакетах всегда указывается формат передаваемых данных (кодек).
Для передачи голоса существует много разнообразных кодеков, с разными соотношениями битрейт/качество/сложность, есть открытые и закрытые. В любом софтфоне обязательно есть поддержка G.711 alaw/ulaw-кодеков, их реализация очень простая, качество звука неплохое, но они требуют пропускной способности в 64 кбит/с. Например, G.729-кодек требует только 8 кбит/с, но очень сильно загружает процессор, к тому же он не бесплатный.
Для передачи факсов обычно используется либо G.711-кодек, либо T.38-протокол. Передача факсов по G.711-кодеку соответствует передаче факса по T.30-протоколу, как будто факс передается по обычной телефонной линии, но при этом аналоговый сигнал с линии оцифровывается по alaw/ulaw-закону. Это также называется передачей факса Inband T.30.
Факсы по T.30-протоколу выполняют согласование своих параметров: скорости передачи, размера дейтаграмм, тип коррекции ошибок. T.38-протокол базируется на протоколе T.30, но в отличие от Inband-передачи, происходит анализ генерируемых и принятых T.30-команд. Таким образом передаются не сырые данные, а распознанные команды управления факсом.
Для передачи команд T.38 используется UDPTL-протокол, это протокол на базе UDP, он используется только для T.38. Для передачи комманд T.38 можно ещё использовать протоколы TCP и RTP, но они используются гораздо реже.
Основные достоинства T.38 - снижение нагрузки на сеть и большая надежность по сравнению с Inband-передачей факса.
Процедура передачи факса в режиме T.38 выглядит следующим образом:
Передавать факсы по интернету желательно в T.38. Если же факс нужно передать внутри офиса или между объектами, имеющими стабильное соединение, то можно использовать передачу факса Inband T.30. При этом перед передачей факса обязательно должна быть отключена процедура эхоподавления, чтобы не вносить дополнительные искажения.
Очень подробно про передачу факсов написано в книге «Fax, Modem, and Text for IP Telephony», авторы - David Hanes и Gonzalo Salgueiro.
С протоколами установления сеанса разговора (SIP/SDP) и методе передачи звука по RTP-каналу мы разобрались. Остался один немаловажный вопрос - качество звука. С одной стороны, качество звука определяется выбранным кодеком. Но с другой, необходимы еще дополнительные процедуры DSP (ЦОС - цифровой обработки сигналов). Данные процедуры учитывают особенности работы VoIP-телефонии: не всегда используется качественная гарнитура, в интернете бывают пропадания пакетов, иногда пакеты приходят неравномерно, пропускная способность сети тоже не резиновая.
Основные процедуры, улучшающие качество звука:
VAD
(Voice activity detector) - процедура определения фреймов, которые содержат голос (активный голосовой фрейм) или тишину (неактивный голосовой фрейм). Такое разделение позволяет заметно снизить загрузку сети, поскольку передача информации о тишине требует гораздо меньше данных (достаточно лишь передать уровень шума или вообще ничего не передавать).
Некоторые кодеки уже содержат внутри себя процедуры VAD (GSM, G.729), для других же (G.711, G.722, G.726) нужно их реализовывать.
Если VAD настроен на передачу информации об уровне шума, то передаются специальные SID-пакеты (Silence Insertion Descriptor) в 13м RTP-формате CN (Comfort Noise).
Стоит заметить, что SID-пакеты могут быть отброшены SIP-прокси-серверами, поэтому для проверки желательно настраивать передачу RTP-трафика мимо SIP-серверов.
CNG
(сomfort noise generation) - процедура генерации комфортного шума на базе сведений из SID-пакетов. Таким образом, VAD и CNG работают в связке, но CNG-процедура гораздо менее востребована, поскольку заметить работу CNG-можно не всегда, особенно при малой громкости.
PLC (packet loss concealment) - процедура восстановления звукового потока при потере пакетов. Даже при 50% потере пакетов хороший алгоритм PLC позволяет добиться приемлемого качества речи. Искажения, конечно, будут, но слова разобрать можно.
Простейший способ эмуляции потери пакетов (в Linux) - воспользоваться утилитой tc из пакета iproute с модулем netem . Она выполняет шейпинг только исходящего трафика.
Пример запуска эмуляции сети с потерей 50% пакетов:
Tc qdisc change dev eth1 root netem loss 50%
Отключение эмуляции:
Tc qdisc del dev eth1 root
Jitter buffer - процедура избавления от jitter-эффекта, когда интервал между принятыми пакетами очень сильно меняется, и что в худшем случае ведет к неверному порядку принимаемых пакетов. Также данный эффект приводит к прерываниям речи. Для устранения jitter-эффекта необходимо на принимаемой стороне реализовать буфер пакетов с размером, достаточным для восстановления исходного порядка отправления пакетов с заданным интервалом.
Эмулировать jitter-эффект также можно с помощью утилиты tc (интервал между ожидаемым моментом прихода пакета и фактическим может достигать 500 мс):
LEC (Line Echo Canceller) - процедура устранения локального эха, когда удаленный абонент начинает слышать собственный голос. Ее суть заключается в том, чтобы вычесть из передаваемого сигнала принимаемый сигнал с некоторым коэффициентом.
Эхо может возникать по нескольким причинам:
Выяснить причину (акустическое или электрическое эхо) несложно: абоненту, на чьей стороне создается эхо, необходимо отключить микрофон. Если эхо все равно возникает - значит оно электрическое.
Более подробно о VoIP и процедурах ЦОС написано в книге VoIP Voice and Fax Signal Processing. Предпросмотр доступен на Google Books .
На этом поверхностный теоретический обзор VoIP завершен. Если интересно, то пример практической реализации мини-АТС на реальной аппаратной платформе можно будет рассмотреть в следующей статье.
[!?] Вопросы и комментарии приветствуются. На них будет отвечать автор статьи Дмитрий Валенто, инженер-программист дизайн-центра электроники Promwad .
Теги:
Современные приложения не могут допустить, чтобы их пакеты поступали с опозданием. Два протокола (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 октетов состоят из следующих полей:
За основным заголовком может следовать одно или более полей идентификаторов отправителей, чьи данные присутствуют в полезной нагрузке. Эти идентификаторы вставляются микшером.
Протокол 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 – для резервирования ресурсов сети.
Основным транспортным протоколом для мультимедийных приложений стал протокол реального времени RTP (Real-Time Protocol), предназначенный для организации передачи пакетов с кодированными речевыми сигналами по IP-сети. Передача пакетов RTP ведется поверх протокола UDP, работающего, в свою очередь, поверх IP (рис. 1.5.).
Рис. 1.5.
На самом деле уровень, к которому относится RTP, не определяется настолько однозначно, как это показано на рис. 1.5 и как это обычно описывается в литературе. С одной стороны, протокол действительно работает поверх UDP, реализуется прикладными программами и, по всем признакам, является прикладным протоколом. Но в то же время, как сказано в начале этого параграфа, RTP предоставляет транспортные услуги независимо от мультимедийных приложений и является, с этой точки зрения, просто транспортным протоколом. Наиболее удачное определение: RTP -- это транспортный протокол, реализованный на прикладном уровне.
Для передачи речевого (мультимедийного) трафика RTP использует пакеты, структура которых показана на рис. 1.6.
Пакет RTP состоит, как минимум, из 12 байтов. В двух первых битах RTP заголовка (поле бита версии, V) указывается версия протокола RTP (в настоящее время это версия 2).
Ясно, что при такой структуре заголовка возможна максимум еще только одна версия RTP. Следующее за ними поле содержит два бита: бит Р, который указывает, были ли добавлены в конце поля с полезной нагрузкой символы-наполнители (они обычно добавляются, если транспортный протокол или алгоритм кодирования требует использования блоков фиксированного размера), и бит X, который указывает, используется ли расширенный заголовок.
Рис. 1.6.
Если он используется, то первое слово расширенного заголовка содержит общую длину расширения. Далее, четыре бита СС определяют число CSRC-полей в конце RTP-заголовка, т.е. число источников, формирующих поток. Маркерный бит М позволяет отмечать то, что стандарт определяет как существенные события, например, начало видеокадра, начало слова в аудиоканале и т.п. За ним следует поле типа данных РТ (7 битов), где указывается код типа полезной нагрузки, определяющий содержимое поля полезной нагрузки - данные приложения {Application Data), например, несжатое 8-битовое аудио МРЗ и т.п. По этому коду приложение может узнать, что нужно делать, чтобы декодировать данные. Остальная часть заголовка фиксированной длины состоит из поля порядкового номера (Sequence Number), поля метки времени (Time Stamp) для записи момента создания первого слова пакета и поля источника синхронизации SSRC, которое идентифицирует этот источник. В последнем поле можно указывать единственное устройство, имеющее только один сетевой адрес, множественные источники, которые могут представить различные мультимедийные среды (аудио, видео и т.д.), или разные потоки одной и той же среды. Так как источники могут быть на разных устройствах, SSRC-идентификатор выбирается случайным образом, чтобы шанс получать данные сразу от двух источников во время RTP-сеанса был минимальным. Однако определен также и механизм решения конфликтов, если они возникают. За фиксированной частью RTP-заголовка могут следовать еще до 15 отдельных 32-разрядных CSRC-полей, которые идентифицируют источники данных.
RTP поддерживается протоколом управления транспортировкой в реальном времени RTCP {Real-Time Transport Control Protocol), который формирует дополнительные отчеты, содержащие информацию о сеансах связи RTP. Напомним, что ни UDP, ни RTP не занимаются обеспечением качества обслуживания QoS (Quality of Service). Протокол RTCP обеспечивает обратную связь с отправителями, а получателям потоков он предоставляет некоторые возможности повышения QoS, информацию о пакетах (потери, задержки, джиттер) и о пользователе (приложении, потоке). Для управления потоком существуют отчеты двух типов - генерируемые отправителями и генерируемые получателями. Например, информация о доле потерянных пакетов и абсолютном количестве потерь позволяет отправителю при получении отчета обнаруживать, что перегрузка канала может заставить получателей не принимать потоки пакетов, которые они ожидали. В этом случае отправитель имеет возможность понизить скорость кодирования, чтобы уменьшить перегрузку и улучшить прием. Отчет отправителя содержит информацию о том, когда был генерирован последний RTP-пакет (она включает в себя как внутреннюю метку, так и реальное время). Эта информация позволяет получателю координировать и синхронизировать множественные потоки, например, видео и аудио. Если поток направляется нескольким получателям, то организуются потоки RTCP-пакетов от каждого из них. При этом будут предприняты шаги для ограничения ширины полосы - обратно пропорционально скорости, с которой генерируются RTCP-отчеты, и числу получателей.
Следует заметить, что хотя RTCP работает отдельно от RTP, но уже и сама цепочка RTP/UDP/IP приводит к существенным накладным расходам (в виде их заголовков). Кодек G.729 генерирует пакеты размером в 10 байтов (80 битов каждые 10 мс). Один RTP-заголовок, размером в 12 байтов, больше, чем весь этот пакет. К нему, кроме того, должен быть добавлен 8-байтовый UDP-заголовок и 20-байтовый IP-заголовок (в версии IРv4), что создает заголовок, в четыре раза превосходящий по размеру передаваемые данные.
