О документе
Рабочая группа по сетевым вопросам B. Thompson
Запрос комментариев: 4170 T. Koren
BCP: 110 D. Wing
Категория: Лучшая современная практика Cisco Systems
Ноябрь 2005
Туннелирование мультиплексированного сжатого RTP (TCRTP)
1. Введение
Этот документ описывает способ объединения существующих протоколов
сжатия, мультиплексирования и туннелирования для экономии полосы
пропускания в некоторых приложениях RTP.
1.1. Является ли полоса пропускания дорогостоящей?
На некоторых каналах, таких как абонентские каналы доступа, стоимость
полосы пропускания широко признаётся существенной проблемой.
протоколы, такие как CRTP (Compressed RTP, [CRTP]), хорошо подходят
для уменьшения неэффективного использования полосы пропускания протоколами,
такими как VoIP, на этих каналах.
Однако многие не осознают стоимость каналов WAN большой
протяжённости. Хотя некоторые технологии передачи голоса по пакетным
сетям, такие как Voice over ATM (VoAAL2, [I.363.2]) и Voice over MPLS,
обеспечивают эффективное использование полосы пропускания (поскольку в
обеих технологиях отсутствуют заголовки IP, UDP и RTP), ни VoATM, ни
VoMPLS не обеспечивают прямого доступа к услугам передачи голоса по
пакетным сетям, доступным для Voice over IP. Следовательно, цели снижения
стоимости каналов WAN достигаются ценой утраченных возможностей
взаимосоединения с другими сетями.
TCRTP устраняет расхождение в использовании полосы пропускания VoIP,
особенно для крупных приложений транкинга голосового трафика.
1.2. Обзор протоколов
Сжатие заголовков выполняется с использованием Enhanced CRTP (ECRTP,
[ECRTP]). ECRTP является усовершенствованием классического CRTP [CRTP],
которое лучше работает на каналах с большой задержкой, таких как
описанные в этом документе туннельные каналы между конечными точками.
Это сжатие заголовков уменьшает заголовки IP, UDP и RTP.
Мультиплексирование выполняется с использованием PPP Multiplexing
[PPP-MUX].
Туннелирование PPP выполняется с использованием L2TP [L2TPv3].
CRTP работает от канала к каналу; то есть для достижения сжатия через
несколько переходов маршрутизаторов CRTP необходимо применять дважды на
каждом маршрутизаторе — один раз на входе и ещё раз на выходе. В отличие
от этого, описанный в настоящем документе TCRTP не требует какой-либо
дополнительной обработки на каждом маршрутизаторе для достижения сжатия
заголовков. Вместо этого заголовки сжимаются между конечными точками, что
экономит полосу пропускания на всех промежуточных каналах.
1.3. Фокус документа
Этот документ в первую очередь рассматривает экономию полосы пропускания
для приложений Voice over IP (VoIP) в сетях с большой задержкой. Однако
описанные в этом документе сочетания протоколов могут использоваться для
обеспечения аналогичной экономии полосы пропускания для других приложений
RTP, таких как видео, и для образцового видеоприложения приведены данные
по экономии полосы пропускания.
1.4. Выбор Enhanced CRTP
CRTP [CRTP] описывает использование сжатия заголовков RTP на
неуказанном транспорте канального уровня, однако обычно используется PPP.
Чтобы CRTP сжимал заголовки, он должен быть реализован на каждом канале
PPP. Для успешной работы CRTP требуется большой объём контекста, а
требования к памяти и обработке высоки, особенно если CRTP должен быть
реализован на нескольких переходах для экономии полосы пропускания на
каждом из переходов. При более высоких скоростях линии потребление
ресурсов процессора CRTP становится чрезмерно дорогим.
Чтобы избежать затрат CRTP на каждом переходе, простое решение состоит
в использовании CRTP с L2TP для получения CRTP между конечными точками.
Однако, как описано в [ECRTP], CRTP пригоден только для каналов с малой
задержкой и малыми потерями. Тем не менее, когда задействовано несколько
переходов маршрутизаторов, ожидание CRTP малой задержки и малых потерь
больше не может быть выполнено. Кроме того, пакеты могут поступать не по
порядку.
Поэтому этот документ описывает использование Enhanced CRTP [ECRTP],
который поддерживает большую задержку, как потерю пакетов, так и нарушение
порядка между компрессором и декомпрессором.
1.5. Снижение накладных расходов TCRTP
Если туннелируется (L2TP) и сжимается (ECRTP) только один поток,
экономия полосы пропускания невелика. Мультиплексирование помогает
распределить накладные расходы заголовка туннеля по многим полезным
нагрузкам RTP. Формат мультиплексирования, предлагаемый этим документом,
— PPP multiplexing [PPP-MUX]. Подробности см. в разделе 2.3.
2. Работа протоколов и рекомендуемые расширения
Этот раздел описывает, как объединить три протокола: Enhanced CRTP,
PPP Multiplexing и туннелирование L2TP, чтобы экономить полосу пропускания
для приложений RTP, таких как Voice over IP.
2.1. Модели
TCRTP обычно может быть реализован двумя способами. Наиболее прямой
способ — реализовать TCRTP в шлюзах, завершающих потоки RTP:
[voice gateway]---[voice gateway]
^
|
TCRTP over IP
Другой способ реализации TCRTP — использование внешнего устройства
концентрации. Это устройство могло бы быть размещено в стратегических
точках сети и могло бы динамически создавать и уничтожать сеансы TCRTP
без участия конечных точек, генерирующих RTP.
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
RTP over IP TCRTP over IP RTP over IP
Такая схема также позволяет использовать классический CRTP [CRTP] на
каналах, где на один канал приходится лишь несколько активных потоков
(где TCRTP неэффективен; см. раздел 3):
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
CRTP over IP TCRTP over IP RTP over IP
2.2. Сжатие заголовков: ECRTP
Как описано в [ECRTP], классический CRTP [CRTP] не пригоден для каналов
WAN с большой задержкой, обычно используемых при туннелировании,
предлагаемом этим документом. Поэтому вместо CRTP следует использовать
ECRTP.
2.2.1. Синхронизация состояний ECRTP
Когда компрессор получает пакет RTP с непредсказанным изменением в
заголовке RTP, компрессору следует отправить пакет COMPRESSED_UDP
(описанный в [ECRTP]) для синхронизации состояния декомпрессора ECRTP.
Пакет COMPRESSED_UDP обновляет контекст RTP в декомпрессоре.
Для обеспечения доставки обновлений переменных контекста пакеты
COMPRESSED_UDP следует доставлять с использованием надёжного режима
работы, описанного в [ECRTP].
Поскольку описанный в [ECRTP] алгоритм «twice» полагается на контрольные
суммы UDP, стек IP на передатчике RTP должен передавать контрольные суммы
UDP. Если контрольные суммы UDP не используются, компрессору ECRTP
следует использовать контрольную сумму CRTP Headers, описанную в [ECRTP].
2.2.2. Пакеты, поступившие не по порядку
Туннельный транспорт не гарантирует упорядоченную доставку пакетов.
Поэтому декомпрессор ECRTP должен корректно работать при наличии пакетов,
поступивших не по порядку.
Порядок пакетов для RTP определяется порядковым номером RTP. Для
повышения устойчивости в случае потери пакетов или изменения порядка
пакетов ECRTP при обновлении переменных контекста отправляет короткие
дельты вместе с полным значением и повторяет обновления в N пакетах, где
N — инженерная константа, настроенная под вид канала, для которого
используется ECRTP.
В отличие от этого, [ROHC] исключает порядковый номер при сжатии, и для
обработки [ROHC] неупорядоченной доставки пакетов по туннелю необходим
другой уровень [REORDER].
2.3. Мультиплексирование: PPP Multiplexing
Как CRTP, так и ECRTP требуют протокол канального уровня, позволяющий
идентифицировать различные протоколы. Для этого подходит [PPP].
Когда CRTP используется внутри туннеля, связанное с CRTP сжатие
заголовков уменьшает размер заголовков IP, UDP и IP пакета IP, переносимого
в туннеле. Однако сам туннель имеет накладные расходы из-за своего
заголовка IP и заголовка туннеля (информации, необходимой для идентификации
туннелируемой полезной нагрузки). Один из способов уменьшить накладные
расходы заголовка IP и заголовка туннеля — мультиплексировать несколько
полезных нагрузок RTP в одном туннелируемом пакете.
[PPP-MUX] описывает инкапсуляцию, объединяющую несколько полезных
нагрузок PPP в одну мультиплексированную полезную нагрузку. PPP
multiplexing позволяет мультиплексировать любой поддерживаемый тип
полезной нагрузки PPP. Затем этот мультиплексированный кадр переносится
как единственная полезная нагрузка PPPMUX в туннеле IP. Это позволяет
переносить несколько полезных нагрузок RTP в одном туннельном пакете IP
и распределять накладные расходы несжатых заголовков IP и туннеля по
нескольким полезным нагрузкам RTP.
При установлении PPP туннеля TCRTP требуются только LCP и IPCP (для
сжатия заголовков) — согласовывать IP-адреса не требуется, равно как не
требуется аутентификация. Подробности см. в разделе 4.1.
2.3.1. Модификации передатчика PPP Multiplex для туннелирования
В разделе 1.2 [PPP-MUX] описана примерная процедура передатчика,
которую можно использовать для реализации передатчика PPP Multiplex. Процедура
передачи, описанная в этом разделе, включает параметр
MAX-SF-LEN, который используется для ограничения максимального размера кадра
PPP Multiplex.
Существуют две причины ограничивать размер кадра PPP Multiplex.
Во-первых, кадр PPPMUX никогда не должен превышать максимальный принимаемый
блок (MRU) физического канала. Во-вторых, когда сеанс PPP и связанное с ним
управление потоком привязаны к физическому каналу, параметр MAX-SF-LEN
образует верхнюю границу времени, в течение которого мультиплексированный
пакет может удерживаться до передачи. Когда управление потоком для
передатчика PPP Multiplex привязано к физическому каналу, тактовая частота
физического канала может использоваться для извлечения кадров из передатчика
PPP Multiplex.
Этот тип управления потоком ограничивает максимальное время, в течение
которого кадр PPP multiplex может удерживаться до передачи, величиной
MAX-SF-LEN / скорость канала.
Интерфейсы туннелей обычно не привязаны к физическим интерфейсам.
Поэтому с туннельным интерфейсом не связана какая-либо известная скорость
передачи. Это означает, что управление потоком в передатчике PPPMUX не может
полагаться на тактовую частоту физического канала для извлечения кадров из
передатчика мультиплексирования. Вместо этого для ограничения времени, в
течение которого кадр PPPMUX может удерживаться до передачи, необходимо
использовать таймер. Таймер вместе с параметром MAX-SF-LEN следует (SHOULD)
использовать для ограничения времени, в течение которого кадр PPPMUX
удерживается до передачи.
Для использования с туннелями следует (SHOULD) внести следующие расширения
в логику передатчика PPPMUX. Логику управления потоком передатчика PPP
следует (SHOULD) изменить так, чтобы она собирала входящие полезные нагрузки,
пока не произойдёт одно из двух событий:
(1) в мультиплексор поступило заданное число октетов, MAX-SF-LEN,
или
(2) истёк таймер с именем T.
Когда выполнено любое из условий, мультиплексированная полезная нагрузка PPP
передаётся.
Назначение MAX-SF-LEN состоит в том, чтобы гарантировать, что полезная
нагрузка PPPMUX не превышает размер MTU любого из возможных физических
каналов, с которыми может быть связан туннель. Значение MAX-SF-LEN следует
(SHOULD) установить меньшим или равным минимуму из MRU-2 (максимальный размер
поля длины) и 16 383 (14 бит) для всех возможных физических интерфейсов, с
которыми может быть связан туннель.
Таймер T устанавливает верхнюю границу задержки для туннельных интерфейсов.
Таймер T сбрасывается всякий раз, когда мультиплексированная полезная
нагрузка передаётся на следующий уровень инкапсуляции. Поведение этого
таймера аналогично Timer_CU AAL2, описанному в [I.363.2]. Каждый передатчик
PPPMUX следует (SHOULD) иметь собственный Timer T.
Оптимальные значения T будут различаться в зависимости от скорости, с которой
полезные нагрузки, как ожидается, будут поступать в мультиплексор, и бюджета
задержки для функции мультиплексирования. Для голосовых приложений значение
T обычно составляло бы 5–10 миллисекунд.
2.3.2. Неэффективности туннелирования
Для получения разумной эффективности использования полосы пропускания при
мультиплексировании внутри туннеля L2TP между источником и назначением
туннеля L2TP должно быть активно несколько потоков RTP.
Если источник и назначение туннеля L2TP совпадают с источником и назначением
сеансов ECRTP, то для получения какой-либо выгоды от мультиплексирования у
источника и назначения должно быть несколько активных потоков RTP.
Из-за этого ограничения TCRTP главным образом полезен для приложений, где
между парой конечных точек RTP выполняется много сеансов RTP. Число
одновременных сеансов RTP, необходимое для уменьшения накладных расходов
заголовка до желаемого уровня, зависит от размера заголовка L2TP. Меньший
заголовок L2TP приведёт к тому, что для достижения эффективности
использования полосы пропускания, аналогичной CRTP, потребуется меньше
одновременных сеансов RTP.
2.4. Туннелирование: L2TP
Туннели L2TP следует (SHOULD) использовать для сквозного туннелирования
полезных нагрузок ECRTP. L2TP включает методы туннелирования сообщений,
используемых при установлении сеанса PPP, таких как NCP. Это позволяет
[IPCP-HC] согласовывать параметры сжатия/распаковки ECRTP.
2.4.1. Туннелирование и DiffServ
Потоки RTP могут маркироваться битами Expedited Forwarding (EF), как описано
в [EF-PHB]. Когда такой пакет туннелируется, заголовок туннеля также должен
(MUST) быть маркирован теми же битами EF, как требуется в [EF-PHB]. Важно не
смешивать трафик EF и не-EF в одном мультиплексированном туннеле,
маркированном EF.
2.5. Форматы инкапсуляции
Формат пакета RTP-пакета, сжатого с помощью сжатия заголовка RTP, как
определено в ECRTP, имеет вид:
+---------+---------+-------------+-----------------------+
| | MSTI | | |
| Context | | UDP | |
| ID | Link | Checksum | RTP Data |
| | Sequence| | |
| (1-2) | (1) | (0-2) | |
+---------+---------+-------------+-----------------------+
Формат мультиплексированного PPP-пакета, определённый в [PPP-MUX], имеет вид:
+-------+---+------+-------+-----+ +---+------+-------+-----+
| Mux |P L| | | | |P L| | | |
| PPP |F X|Len1 | PPP | | |F X|LenN | PPP | |
| Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN|
| Field | | Field1| | | |FieldN | |
| (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | |
+-------+----------+-------+-----+ +----------+-------+-----+
Комбинированный формат, используемый для TCRTP с одной полезной нагрузкой,
представляет собой все приведённые выше пакеты, объединённые конкатенацией.
Ниже приведён пример с одной полезной нагрузкой:
+------+-------+----------+-------+-------+-----+-------+----+
| IP | Mux |P L| | | | MSTI| | |
|header| PPP |F X|Len1 | PPP |Context| | UDP |RTP |
| (20) | Proto |F T| | Proto | ID | Link| Cksum |Data|
| | Field | | Field1| | Seq | | |
| | (1) |1-2 octets| (0-2) | (1-2) | (1) | (0-2) | |
+------+-------+----------+-------+-------+-----+-------+----+
|<------------- IP payload ------------------------->|
|<----- PPPmux payload --------------------->|
Если туннель содержит мультиплексированный трафик, в одном IP-пакете
передаётся несколько «полезных нагрузок PPPMux».
3. Эффективность использования полосы пропускания
Ожидаемая эффективность использования полосы пропускания, достижимая с TCRTP,
зависит от ряда факторов. Эти факторы включают выигрыш от
мультиплексирования, ожидаемую частоту потери пакетов в сети и скорости
изменения конкретных полей в заголовках IP и RTP. В этом разделе также
описывается, как TCRTP значительно повышает эффективность использования
полосы пропускания для передачи голоса по IP через ATM.
3.1. Выигрыш от мультиплексирования
Мультиплексирование сокращает накладные расходы, связанные с заголовками
уровня 2 и туннеля. Увеличение числа полезных нагрузок CRTP, объединяемых в
одну мультиплексированную полезную нагрузку PPP, увеличивает выигрыш от
мультиплексирования. По мере увеличения трафика в туннеле в одну
мультиплексированную полезную нагрузку объединяется больше полезных нагрузок.
Это увеличивает выигрыш от мультиплексирования.
3.2. Частота потери пакетов
Потеря мультиплексированного пакета вызывает потерю пакетов для всех потоков,
содержащихся в мультиплексированном пакете.
Когда ожидаемая частота потерь в туннеле относительно низка (возможно, менее
5%), устойчивой работы (описанной в [ECRTP]) должно быть достаточно
для обеспечения доставки изменений состояния. Эта устойчивая работа
характеризуется параметром N, который означает, что вероятность потери более
чем N соседних пакетов в туннеле мала.
Значение N=1 защитит от потери одного пакета в сжатом сеансе ценой полосы
пропускания. Значение N=2 защитит от потери двух следующих подряд пакетов в
сжатом сеансе и так далее. Более высокие значения N сопряжены с большими
потерями полосы пропускания.
Оптимальное значение N будет зависеть от частоты потерь в туннеле. Если
частота потерь высока (возможно, выше 5%), необходимо применять более
продвинутые методы. Эти методы выходят за рамки настоящего документа.
3.3. Расчёт полосы пропускания для голосовых и видеоприложений
Следующая формула использует описанные выше факторы для моделирования
использования полосы пропускания на поток как для голосовых, так и для
видеоприложений. Определяются следующие переменные:
SOV-TCRTP, единица: октет. Накладные расходы ECRTP и
мультиплексированного заголовка PPP на полезную нагрузку. Это значение
не включает дополнительные накладные расходы на обновление полей IP ID
или RTP Time Stamp (подробности об IP ID см. в [ECRTP]). Значение
предполагает использование типа полезной нагрузки COMPRESSED_RTP. Оно
состоит из 1 октета для идентификатора контекста ECRTP, 1 октета для
флагов COMPRESSED_RTP, 2 октетов для контрольной суммы UDP, 1 октета
для идентификатора протокола PPP и 1 октета для поля длины
мультиплексированного PPP. Всего 6 октетов.
POV-TCRTP, единица: октет. Накладные расходы туннелированного ECRTP на
пакет. Это накладные расходы на заголовок туннеля и тип полезной
нагрузки мультиплексированного PPP. Это значение составляет 20 октетов
для заголовка IP, 4 октета для заголовка L2TPv3 и 1 октет для
идентификатора протокола мультиплексированного PPP. Всего 25 октетов.
TRANSMIT-LENGTH, единица: миллисекунды. Средняя продолжительность передачи
(например, речевого отрезка для голосовых потоков).
SOV-TSTAMP, единица: октет. Дополнительные накладные расходы заголовка
COMPRESSED_UDP на полезную нагрузку, включающего поле абсолютной
временной метки. Это значение включает 1 октет для поля дополнительных
флагов в заголовке COMPRESSED_UDP и 4 октета для абсолютной временной
метки, всего 5 октетов.
SOV-IPID, единица: октет. Дополнительные накладные расходы заголовка
COMPRESSED_UDP на полезную нагрузку, включающего поле абсолютного IPID.
Это значение включает 2 октета для абсолютного IPID. Это значение также
включает 1 октет для поля дополнительных флагов в заголовке
COMPRESSED_UDP. Всего 3 октета.
IPID-RATIO, единица: целые значения 0 или 1. Указывает частоту, с которой
IPID будет обновляться компрессором. Если IPID изменяется случайным
образом и поэтому всегда нуждается в обновлении, значение равно 1. Если
IPID изменяется на постоянную фиксированную величину между полезными
нагрузками потока, то IPID-RATIO будет равно 0. Значение этой переменной
не учитывает значение IPID в начале голосовой или видеопередачи,
поскольку оно учитывается переменной TRANSMIT-LENGTH. Это поведение
контролируется реализацией отправляющего стека IP и приложения RTP. См.
раздел 1.1.
NREP, единица: целое число (обычно число от 1 до 3). Это число повторений поля
обновления в заголовках ECRTP для увеличения скорости доставки между
компрессором и декомпрессором. Для данного примера предполагается
NREP=2.
PAYLOAD-SIZE, единица: октеты. Размер полезной нагрузки RTP в октетах.
MUX-SIZE, единица: количество. Число полезных нагрузок PPP, мультиплексированных
в одну мультиплексированную полезную нагрузку PPP.
SAMPLE-PERIOD, единица: миллисекунды. Средняя задержка между передачами
голосовых или видеополезных нагрузок для каждого потока в
мультиплексе. Например, в голосовых приложениях значение этой переменной
составляло бы 10 мс, если все вызовы имеют период дискретизации 10 мс.
Формула имеет вид:
SOV-TOTAL = SOV-TCRTP + SOV-TSTAMP * (NREP * SAMPLE-PERIOD /
TRANSMIT-LENGTH) + SOV-IPID * IPID-RATIO
BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) *
8) / SAMPLE-PERIOD)
Результаты:
BANDWIDTH, единица: килобиты в секунду. Средний объём
полосы пропускания, используемый на голосовой или видеопоток.
SOV-TOTAL = Общая величина накладных расходов на полезную нагрузку,
связанных с туннелированным ECRTP. Она включает накладные
расходы ECRTP и PPP на полезную нагрузку, накладные расходы на
обновление временной метки и накладные расходы на обновление
IPID.
3.3.1. Пример расчёта полосы пропускания для голоса
Чтобы создать пример для голосового приложения с использованием приведённых
выше формул, предположим следующий сценарий использования. Сжатые голосовые
потоки с использованием сжатия G.729 с периодом пакетизации 20 миллисекунд.
В этом сценарии включён VAD, а средняя длина речевого отрезка составляет 1500
миллисекунд. Поле IPID изменяется случайным образом между полезными нагрузками
потоков. В туннеле достаточно трафика, чтобы допустить 3 мультиплексированные
полезные нагрузки. Применяются следующие значения:
SAMPLE-PERIOD = 20 milliseconds
TRANSMIT-LENGTH = 1500 milliseconds
IPID-RATIO = 1
PAYLOAD-SIZE = 20 octets
MUX-SIZE = 3
В данном примере пропускная способность на один вызов составляет 16,4 кбит/с. Классический CRTP по одному каналу HDLC с использованием тех же указанных выше коэффициентов даёт 12,4 кбит/с.
Влияние IPID может существенно сказываться на пропускной способности на один вызов. Если приведённый выше пример пересчитать с использованием IPID-RATIO, равного 0, то пропускная способность на один вызов уменьшается до 13,8 кбит/с. Классический CRTP по одному каналу HDLC с использованием этих же коэффициентов даёт 11,2 кбит/вызов.
3.3.2. Таблица сравнения пропускной способности для голосовой связи
При использовании 5 одновременных вызовов, без обнаружения голосовой активности (VAD), G.729 с интервалом пакетизации 20 мс и без учёта накладных расходов RTCP значения пропускной способности таковы:
Обычный VoIP по PPP: 124 кбит/с
с классическим CRTP на канале: 50 кбит/с (экономия: 59%)
с TCRTP по PPP: 62 кбит/с (экономия: 50%)
с TCRTP по AAL5: 85 кбит/с (экономия: 31%)
3.3.3. Пример расчёта пропускной способности для видео
Поскольку TCRTP может использоваться для экономии пропускной способности при любом потоке, инкапсулированном в RTP, он может использоваться для экономии пропускной способности в видеоприложениях. В этом разделе документируется пример экономии пропускной способности на основе TCRTP для видео, закодированного MPEG-2.
Чтобы создать пример для видеоприложения с использованием приведённых выше формул, предположим следующий сценарий использования. Инкапсуляция в RTP системных и транспортных потоков MPEG выполняется, как описано в RFC 2250. Кадры для видео, закодированного MPEG-2, передаются непрерывно, поэтому переменная TRANSMIT-LENGTH в формуле пропускной способности по существу бесконечна. Поле IPID случайным образом изменяется между полезными нагрузками потоков. В туннеле достаточно трафика, чтобы допустить 3 мультиплексированные полезные нагрузки. Применяются следующие значения:
SAMPLE-PERIOD = 2,8 миллисекунды
TRANSMIT-LENGTH = бесконечность
IPID-RATIO = 1
PAYLOAD-SIZE = 1316 октетов
MUX-SIZE = 3
В данном примере пропускная способность на один поток составляет 3,8 Мбит/с. Видео MPEG без сжатия заголовков с использованием тех же указанных выше коэффициентов даёт 3,9 Мбит/с. Хотя TCRTP действительно обеспечивает некоторую экономию пропускной способности для видео, отношение заголовков передачи к полезной нагрузке настолько мало, что экономия пропускной способности незначительна.
3.3.4. TCRTP по ATM
Передача IP по AAL5 вызывает эффект квантования использования пропускной способности, поскольку пакеты всегда кратны ячейкам ATM.
Например, размер полезной нагрузки для G.729 при интервалах пакетизации 10 миллисекунд составляет 10 октетов. Это значительно меньше размера полезной нагрузки ячейки ATM (48 октетов). Когда классический CRTP [CRTP] используется на основе «канал—канал», отношение накладных расходов IP к полезной нагрузке довольно хорошее. Однако инкапсуляция AAL5 и заполнение её ячеек всегда принуждают минимальный размер полезной нагрузки к размеру одной ячейки ATM, что приводит к плохому использованию пропускной способности.
Вместо расходования этого заполнения впустую мультиплексирование TCRTP позволяет этому ранее неиспользуемому пространству в ячейке ATM содержать полезные данные. Это одна из главных причин, по которым мультиплексирование оказывает столь большое влияние на использование пропускной способности при передаче голоса по IP через ATM.
Такая эффективность мультиплексирования TCRTP сходна с мультиплексированием подъячеек AAL2, описанным в [I.363.2]. Однако, в отличие от мультиплексирования подъячеек AAL2, эффективность мультиплексирования TCRTP не ограничивается только сетями ATM.
3.3.5. TCRTP по сетям, не являющимся ATM
Когда TCRTP используется с другими инкапсуляциями уровня 2, не имеющими минимального размера PDU, выгода от мультиплексирования не столь велика.
В зависимости от точных накладных расходов инкапсуляции уровня 2 выгода от мультиплексирования может быть немного лучше или хуже, чем сжатие заголовков CRTP «канал—канал». Накладные расходы туннелирования CRTP на одну полезную нагрузку составляют либо 4, либо 6 октетов. Если классический CRTP плюс накладные расходы уровня 2 превышают это значение, мультиплексирование TCRTP будет потреблять меньше пропускной способности, чем классический CRTP, когда внешний заголовок IP амортизируется на большом числе полезных нагрузок.
Точку безубыточности по полезным нагрузкам можно определить следующей формулой:
POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX + SOV-PPPMUX
* MUX-SIZE
Где:
POV-L2, единица: октет. Накладные расходы пакета уровня 2: 5 октетов для инкапсуляции HDLC
POV-TUNNEL, единица: октет. Накладные расходы пакета вследствие туннелирования: 24 октета заголовка IP и заголовка L2TPv3
POV-PPPMUX, единица: октет. Накладные расходы пакета для идентификатора протокола мультиплексированного PPP: 1 октет
SOV-PPPMUX, единица: октет. Накладные расходы PPPMUX на одну полезную нагрузку, состоящие из поля длины полезной нагрузки и идентификатора протокола ECRTP. Значение SOV-PPPMUX обычно составляет 1, 2 или 3.
Если в качестве протокола уровня 2 используется HDLC, точка безубыточности (при использовании приведённой выше формулы) достигается, когда MUX-SIZE = 7. Таким образом, необходимо мультиплексировать 7 голосовых или видеопотоков, чтобы TCRTP был столь же эффективен с точки зрения пропускной способности, как сжатие CRTP «канал—канал».
4. Пример реализации TCRTP
В этом разделе описывается пример реализации TCRTP. Реализации TCRTP могут быть выполнены многими способами, при условии соблюдения требований соответствующих RFC.
Ниже приведён путь, который проходит пакет RTP в этой реализации:
+-------------------------------+ ^
| Приложение | |
+-------------------------------+ |
| RTP | |
+-------------------------------+ Приложение и
| UDP | стек IP
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| Пересылка IP
|
+-------------------------------+ ^
| ECRTP | |
+-------------------------------+ |
| PPPMUX | |
+-------------------------------+ Интерфейс
| PPP | туннеля
+-------------------------------+ |
| L2TP | |
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| Пересылка IP
|
+-------------------------------+ ^
| Уровень 2 | |
+-------------------------------+ Физический
| Физический | интерфейс
+-------------------------------+ V
Стек протоколов настраивается для создания интерфейса туннеля L2TP к хосту назначения. Туннель настраивается для согласования соединения PPP (с использованием NCP IPCP) со сжатием заголовков ECRTP и PPPMUX. Пересылка IP настраивается для маршрутизации пакетов RTP в этот туннель. Номер UDP-порта назначения мог бы отличать пакеты RTP от пакетов, не являющихся RTP.
Передающее приложение собирает данные RTP из одного источника и формирует пакет RTP. Прикладные уровни нижнего уровня добавляют заголовки UDP и IP, образуя полный пакет IP.
Пакеты RTP маршрутизируются в интерфейс туннеля, где заголовки сжимаются, полезные нагрузки мультиплексируются, а затем пакеты туннелируются к хосту назначения.
Работа принимающего узла аналогична работе передающего узла в обратном порядке.
4.1. Предлагаемое согласование PPP и L2TP для TCRTP
В этом разделе описываются необходимые согласования PPP и LT2P, необходимые для установления соединения PPP и туннеля L2TP со сжатием заголовков L2TP. Согласование происходит между двумя одноранговыми узлами: Peer1 и Peer2.
4.2. Согласование PPP TCRTP
Протокол Point-to-Point Protocol описан в [PPP].
4.2.1. Согласование LCP
Link Control Processing (LCP) описан в [PPP].
4.2.1.1. Установление канала
Peer1 Peer2
----- -----
Configure-Request (no options) ->
<- Configure-Ack
<- Configure-Request (no options)
Configure-Ack ->
4.2.1.2. Завершение работы канала
Terminate-Request ->
<- Terminate-Ack
4.2.2. Согласование IPCP
Описанный здесь обмен протоколами приведён в [IPHCOMP], [PPP] и [ECRTP].
Peer1 Peer2
----- -----
Configure-Request ->
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[IPCP-HC] and [ECRTP]
<- Configure-Ack
<- Configure-Request
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[IPCP-HC] and [ECRTP]
Configure-Ack ->
4.3. Согласование L2TP
L2TP описан в [L2TPv3].
4.3.1. Установление туннеля
Peer1 Peer2
----- -----
SCCRQ ->
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
<- SCCRP
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
SCCCN ->
Mandatory AVP's:
Message Type
<- ZLB
4.3.2. Установление сеанса
Peer1 Peer2
----- -----
ICRQ ->
Mandatory AVP's:
Message Type
Assigned Session ID
Call Serial Number
<- ICRP
Mandatory AVP's:
Message Type
Assigned Session ID
ICCN ->
Mandatory AVP's:
Message Type
Tx (Connect Speed)
Framing Type
<- ZLB
4.3.3. Завершение работы туннеля
Peer1 Peer2
----- -----
StopCCN ->
Mandatory AVP's:
Message Type
Assigned Tunnel ID
Result Code
<- ZLB
5. Соображения безопасности
В этом документе описывается метод объединения нескольких существующих протоколов, реализующих сжатие, мультиплексирование и туннелирование потоков RTP. Атаки на составные технологии TCRTP включают атаки на заголовки и полезные нагрузки RTP/RTCP, передаваемые в сеансе TCRTP, атаки на сжатые заголовки, атаки на уровень мультиплексирования либо атаки на согласование туннелирования или транспорт. Проблемы безопасности, связанные по отдельности с каждой из этих составных технологий, рассматриваются в соответствующих спецификациях [ECRTP], [PPP-MUX], [L2TPv3] наряду с соображениями безопасности для самого RTP [RTP].
Однако при совместном использовании этих составных технологий могут возникать дополнительные соображения безопасности. Например, вследствие сбоя протокола или ошибки данных может существовать повышенный риск непреднамеренной ошибочной доставки пакетов из одного потока в мультиплексе в другой, поскольку адресная информация более сжата. Это особенно верно, если туннель передаётся по протоколу канального уровня, допускающему доставку пакетов, содержащих битовые ошибки, в сочетании с параметром транспортного уровня туннеля, не проверяющим контрольной суммой всю полезную нагрузку.
Возможность злонамеренного перенаправления может быть выше по сравнению
с таковой для одного потока RTP, передаваемого отдельно, поскольку
адресная информация должна оставаться незашифрованной, чтобы могли
функционировать уровни сжатия заголовков и мультиплексирования.
Основной защитой от ошибочной доставки является обеспечение непригодности
данных для непредназначенных получателей с помощью криптографических
методов. Базовый метод шифрования, предусмотренный в спецификации RTP
[RTP], не подходит, поскольку он шифрует заголовки RTP и RTCP вместе с
полезной нагрузкой. Однако спецификация RTP также допускает определение
альтернативных подходов в отдельных спецификациях профилей или форматов
полезной нагрузки, в которых шифровалась бы только часть пакета,
составляющая полезную нагрузку; поэтому к зашифрованным пакетам может
применяться сжатие заголовков. Один такой профиль, [SRTP], предоставляет
более
совершенные и полные методы шифрования и аутентификации сообщений, чем
базовый подход в [RTP]. В будущем могут быть разработаны дополнительные
методы. Во все приложения TCRTP следует включать надлежащую
криптографическую защиту.
6. Благодарности
Авторы хотели бы поблагодарить авторов RFC 2508, Stephen Casner и Van
Jacobson, а также авторов RFC 2507, Mikael Degermark, Bjorn Nordgren и
Stephen Pink.
Авторы также хотели бы поблагодарить Dana Blair, Alex Tweedley, Paddy
Ruddy, Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama,
Mallik Tatipamula, Mike Thomas, Mark Townsley, Andrew Valencia, Herb
Wildfeuer, J. Martin Borden, John Geevarghese и Shoou Yiu.
7.1. Нормативные ссылки
[PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing",
RFC 3153, August 2001.
[ECRTP] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
High Delay, Packet Loss and Reordering", RFC 3545, July
2003.
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Links", RFC 2508, February 1999.
[IPHCOMP] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[IPCP-HC] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP
Header Compression over PPP", RFC 3544, July 2003.
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2
AAL", I.363.2, September 1997.
[EF-PHB] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis,
"An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002.
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
7.2. Информационные ссылки
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[REORDER] G. Pelletier, L. Jonsson, K. Sandlund, "RObust Header
Compression (ROHC): ROHC over Channels that can Reorder
Packets", Work in Progress, June 2004.
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
T., Yoshimura, T., and H. Zheng, "RObust Header Compression
(ROHC): Framework and four profiles: RTP, UDP, ESP, and
uncompressed ", RFC 3095, July 2001.