Требования к современным IP-сетям
В главе 3 были рассмотрены принципы кодирования речевой информации, используемые для передачи ее по сетям с маршрутизацией пакетов IP. Закодированные при помощи таких алгоритмов данные генерируются с заданной (не обязательно фиксированной) скоростью независимо от загрузки сети. Требуется, чтобы информация была доставлена получателю с точно той же скоростью, с какой ее генерировал отправитель. Аналогичное требование предъявляется и к доставке видеоинформации.
Синхронная передача данных предполагает периодическую генерацию битов, байтов, или пакетов, которые должны быть воспроизведены приемником с точно таким же периодом. В данном случае скорость передачи информации постоянна. ТфОП функционирует на основе синхронной передачи данных, примером может служить цифровой поток Е1.
Передача такого рода информации (аудио, видео, синхронные потоки) сама по себе не требует очень малой задержки между источником и приемником, хотя это часто является предпочтительным. Однако принципиально необходимо, чтобы задержка была предсказуема, так как только в этом случае временные параметры переданных сообщений могут быть восстановлены в приемнике.
Требования к скорости передачи информации для разных услуг варьируются очень широко. Например, передача данных телеметрии в реальном времени может требовать скорости несколько бит/с, для речевой информации удовлетворительного качества потребуется от 4 до 32 Кбит/с, для обеспечения качества на уровне ТфОП необходимо до 64 Кбит/с, передача видео требует от десятков Кбит/с до десятков Мбит/с (HDTV), в зависимости от характеристик системы (размер изображения, частота кадров, способ кодирования и т.д.). Требования ко времени доставки тоже могут быть различны. Например, при организации речевой связи допускается сквозная задержка от 12 мс при отсутствии эхокомпенсации (G.164), и до 400 мс при ее наличии. При этом, как отмечалось в главе 3, при стремлении величины задержки к верхнему пределу субъективная оценка качества связи падает, взаимодействие становится полудуплексным.
Для не интерактивных приложений (например, предоставление видеоинформации по запросу) могут допускаться задержки более 500 мс, которые ограничиваются только возможностью пользователя нормально управлять процессом воспроизведения и возможностями буферизации данных в приемнике.
Процесс передачи данных по сетям с коммутацией пакетов подвержен влиянию статистически изменяющейся задержки (джиттера), возникающей при обработке очередей в узлах сети. Джиттер компенсируется приемником путем использования буфера воспроизведения. Приемник должен обладать информацией о статистических характеристиках задержки, чтобы предусмотреть необходимое место в буферном накопителе. Например, если допустимы потери 0,1% пакетов, величина буфера должна поддерживаться на уровне, превышающем переменную составляющую задержки поступающих пакетов в 99,9% случаев. Таким образом, высокий уровень джиттера заставляет мириться либо с большим количеством мест в буферном накопителе и, как следствие, с большими задержками, либо с высоким уровнем потерь информации.
Сеть Интернет была создана для передачи данных на основе адаптивной маршрутизации, предполагающей, что данные могут следовать по разным маршрутам, выбираемым в зависимости от некоторых условий. Кроме того, в сети Интернет не предусматривалось установление соединения между источником и приемником информации, т.е. между компьютерами в сети не устанавливается никаких связей, информация о которых сохранялась бы в сети. Это приводит к тому, что пакеты часто приходят к получателю не в той последовательности, в какой они были переданы.
Интернет - сеть с доставкой по мере возможности. Это значит, что сеть пытается доставить информацию, но если это по каким-либо причинам не получается, то информация будет потеряна. Потери пакетов в Интернет, к сожалению, носят “пачечный” характер, то есть внутри некоторых интервалов времени теряется сразу много пакетов подряд или пакетов, следующих с небольшими промежутками. Эта характеристика сети Интернет затрудняет организацию передачи мультимедийной информации, поскольку такие приложения нормально работают только в условиях случайных независимых потерь.
Интернет - сеть, которая сегодня поддерживает только одноадресную доставку. Многоадресная доставка информации, очень полезная для многих приложений (организация конференций, трансляция телепрограмм и т.д.), поддерживается только в экспериментальном режиме на некоторых участках.
Кроме того, сегодня Интернет предоставляет любым приложениям и любым пользователям одинаковый (и притом, как уже говорилось, не гарантированный и не специфицированный) уровень качества обслуживания. Это не позволяет сравнивать качество услуг IP-телефонии с качеством услуг ТфОП, так как в ТфОП существуют и действуют очень жесткие спецификации качества обслуживания вызовов. Для решения названной проблемы необходимо обеспечить возможность резервирования ресурсов сети в процессе установления соединений.
Скажем несколько слов о надежности. Стремление обеспечить в рамках IP-сетей предоставление услуг телефонии, аналогичных услугам ТфОП, сталкивается с проблемой физической надежности сети. Пользователи ТфОП привыкли, что услуги доступны 24 часа в сутки 7 дней в неделю, т.е. всегда. Эта привычка вполне обоснована, так как АТС и другое оборудование, составляющее основу ТфОП, разработано с учетом коэффициента готовности 99.999%, что эквивалентно 3 часам простоя за 40 лет (!) эксплуатации. Так исторически сложилось, что в мире сетей передачи данных действуют совершенно другие стандарты. Большинство людей не смогут ответить, когда последний раз не работал их телефон, однако они без труда припомнят, когда отказала локальная сеть, или не было доступа к Интернет. Создание универсальной сетевой инфраструктуры на базе протокола IP потребует пересмотреть требования к надежности IP-сетей.
Подводя итог, отметим, что Интернет в сегодняшнем состоянии, со всеми отмеченными выше свойствами, вполне удовлетворяет требованиям наиболее популярных приложений (WWW, электронная почта, передача файлов и т.д.), однако, как мы увидим ниже, для поддержки новых услуг, в том числе аналогичных по сути и качеству услугам ТфОП, необходима глубокая поэтапная модернизация сети с внедрением новых протоколов и алгоритмов обслуживания трафика.
4.10 Протоколы RTP и RTCP
Приложения, обеспечивающие передачу речевой и видеоинформации, используют сервис транспортного уровня без установления соединений (например, UDP). При этом каждое приложение может обеспечивать формирование полезной нагрузки пакетов специфическим образом, включая необходимые для функционирования поля и данные. Однако, как показал приведенный в предыдущем параграфе анализ, данные разной природы (речь, видео) имеют общие особенности, которые требуют обеспечения вполне определенной функциональности при их передаче по сети. Это позволяет сформировать некий общий транспортный уровень, объединяющий функции, общие для потоковых данных разной природы, и используемый всеми соответствующими приложениями, придав протоколу этого уровня статус стандарта. Комитетом IETF был разработан протокол транспортировки информации в реальном времени - Realtime Transport Protocol (RTP), который стал базисом практически для всех приложений, связанных с интерактивной передачей речевой и видеоинформации по сети с маршрутизацией пакетов.
Характерные для IP-сетей временные задержки и вариация задержки пакетов (джиттер) могут серьезно исказить информацию, чувствительную к задержке, например, речь и видеоинформацию, сделав ее абсолютно непригодной для восприятия. Отметим, что вариация задержки пакетов гораздо сильнее влияет на субъективную оценку качества передачи, чем абсолютное значение задержки.
Уже длительное время ведется работа по созданию методов уменьшения джиттера и задержек. Для этого могут применяться рассмотренные в главе 10 механизмы, обеспечивающие пользователю заданный уровень качества обслуживания. Они, конечно, улучшают качество услуг, предоставляемых сетью, но не могут совсем устранить образование очередей в сетевых устройствах и совсем убрать джиттер.
Именно протокол RTP позволяет компенсировать негативное влияние джиттера на качество речевой и видеоинформации. В то же время, он не имеет собственных механизмов, гарантирующих своевременную доставку пакетов или другие параметры качества услуг, -это осуществляют нижележащие протоколы.
Он даже не обеспечивает все те функции, которые обычно предоставляют транспортные протоколы, в частности функции исправления ошибок и управления потоком. Обычно протокол RTP базируется на протоколе UDP и использует его функции, но может работать и поверх других транспортных протоколов.
Существует несколько серьезных причин, по которым такой распространенный транспортный протокол, как TCP, плохо подходит для передачи чувствительной к задержкам информации. Во-первых, это алгоритм надежной доставки пакетов. Пока отправитель повторно передаст пропавший пакет, получатель будет ждать, результатом чего может быть недопустимое увеличение задержки. Во-вторых, алгоритм управления при перегрузке в протоколе TCP далеко не оптимален для передачи речи и видеоинформации. При обнаружении потерь пакетов протокол TCP уменьшает размер окна, а затем будет его медленно увеличивать. Однако передача речевой и видеоинформации осуществляется на вполне определенных, фиксированных скоростях, которые нельзя мгновенно уменьшить, не ухудшив качество предоставляемых услуг. Правильной реакцией на перегрузку для информационных потоков этих типов было бы изменение метода кодирования, частоты видеокадров или размера видеоизображения.
Протокол RTP предусматривает индикацию типа полезной нагрузки и порядкового номера пакета в потоке, а также применение временных меток. Отправитель помечает каждый RTP-пакет временной меткой, получатель извлекает ее и вычисляет суммарную задержку. Разница в задержке разных пакетов позволяет определить джиттер и смягчить его влияние - все пакеты будут выдаваться приложению с одинаковой задержкой.
Итак, главная особенность RTP - это вычисление средней задержки некоторого набора принятых пакетов и выдача их пользовательскому приложению с постоянной задержкой, равной этому среднему значению. Однако следует иметь в виду, что временная метка RTP соответствует моменту кодирования первого дискретного сигнала пакета. Поэтому, если RTP-пакет, например, с видеоинформацией, разбивается на блоки данных нижележащего уровня, то временная метка уже не будет соответствовать истинному времени их передачи, поскольку они перед передачей могут быть установлены в очередь.
На рис. 4.7 представлен основной заголовок RTP-пакета, содержащий ряд полей, которые идентифицируют такие элементы, как формат пакета, порядковый номер, источник информации, границы и тип полезной нагрузки.
V (2 бита) - поле версии протокола. Текущая версия протокола -вторая.
Р (1 бит) - поле заполнения. Сигнализирует о наличии заполнения в конце поля полезной нагрузки. Заполнение применяется, когда приложение требует, чтобы размер полезной нагрузки был кратен, например, 32 битам.
Х (1 бит) - поле расширения заголовка. Служит для индикации того, что за основным заголовком следует дополнительный заголовок, используемый в экспериментальных расширениях протокола RTP.
СС (4 бита) - поле отправителей. Содержит идентификаторы отправителей, чьи данные находятся в пакете, причем сами идентификаторы следуют за основным заголовком.
М (1 бит) - поле маркера. Обычно используется для указания границ потока данных. Смысл бита маркера зависит от типа полезной нагрузки. В случае передачи видеоинформации он определяет конец кадра. При передаче речевой информации маркер указывает начало периода активности после периода молчания.
РТ (7 битов) - поле типа полезной нагрузки. Идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование. В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в ответ на изменение условий, если об этом сигнализирует протокол управления транспортировкой информации в реальном времени (Real-Time Transport Control Protocol).
Порядковый номер пакета (Sequence Number, 16 битов). Каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым переданным пакетом RTP.
Это позволяет обнаруживать потери пакетов и определять порядок пакетов с одинаковым временным штампом. Несколько последовательных пакетов могут иметь один и тот же штамп, если логически они порождены в один и тот же момент, как, например, пакеты, принадлежащие одному и тому же видеокадру.
Временной штамп (Timestamp, 32 бита). Момент времени, в который был создан первый октет данных полезной нагрузки. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя.
Идентификатор SSRC (Synchronization Source Identifier, 32 бита) -поле идентификатора источника синхронизации. Псевдослучайное число, которое уникальным образом идентифицирует источник в течение сеанса и не зависит от сетевого адреса. Это число играет важную роль при обработке порции данных, поступившей от одного источника.
Идентификатор CSRC (Contributing Source Identifier, 32 бита) - список полей идентификаторов источников, участвующих в создании RTP-пакета. Устройство смешивания информации (миксер) вставляет целый список SSRC идентификаторов источников, которые участвовали в построении данного RTP-пакета. Количество элементов в списке: от 0 до 15. Если число участников более 15, выбираются первые 15. Примером может служить речевая конференция, в которой передаются RTP-пакеты с речью всех участников - каждый со своим идентификатором SSRC. Они-то и образуют список идентификаторов CSRC. Вся конференция имеет общий идентификатор SSRC.
Доставка RTP-пакетов контролируется специальным протоколом RTCP (Real Time Control Protocol).
Основной функцией протокола RTCP является организация обратной связи приемника с отправителем информации для отчета о качестве получаемых данных. Протокол RTCP передает сведения (как от приемника, так и от отправителя) о числе переданных и потерянных пакетов, значении джиттера, задержке и т.д. Эта информация может быть использована отправителем для изменения параметров передачи, например для уменьшения коэффициента сжатия информации с целью улучшения качества ее передачи. Более подробное описание протоколов RTP и RTCP можно найти в RFC-1889.
4.11 Многоадресная рассылка
Основной целью группового вещания является создание эффективного механизма передачи данных по схеме “один-ко-многим” и “многие-ко-многим”.
Традиционные механизмы доставки пакетов стека TCP/IP мало пригодны для поддержки группового вещания. Например, использование уникальных адресов (unicast) приводит к необходимости установления многочисленных двухточечных соединений между отправителем и каждым из получателей.
Другим способом передачи данных является широковещательная передача, когда станция направляет пакеты, используя широковещательные адреса (broadcast). Пакеты с такими адресами передаются ко всем конечным узлам указанной сети, независимо оттого, нужны ли они каждому из них. Во многих ситуациях такой способ передачи также оказывается неэффективным вследствие своей избыточности, которая ведет к чрезмерному росту трафика, особенно в крупных сетях.
В случае использования групповых адресов отправитель передает сообщение только один раз, затем оно тиражируется и доставляется только к тем узлам, которые являются членами соответствующей группы. Такой режим экономит пропускную способность за счет передачи только того трафика, который необходим. Номера группы задаются с использованием IP-адреса типа multicast.
Основными протоколами, на базе которых реализуется многоадресная рассылка в IP-сетях, являются протоколы IGMP (Internet Group Management Protocol), DVMRP - (Distance Vector Multicast Routing Protocol), PIM (Protocol Independent Multicast).
