Tunneling Multiplexed Compressed RTP (TCRTP)
RFC 4170 описывает TCRTP — способ повысить эффективность использования полосы пропускания при параллельной передаче нескольких RTP-потоков между двумя конечными точками, в частности для магистральной передачи голоса. Метод объединяет Enhanced CRTP (ECRTP) для сжатия заголовков, PPP Multiplexing для мультиплексирования полезных нагрузок и L2TP для сквозного туннелирования. Документ приводит рекомендуемые расширения и примеры расчёта эффективности для голосовых и видеоприложений. Во все приложения TCRTP следует включать подходящую криптографическую защиту. RFC 4170 имеет статус Best Current Practice (BCP 110).
Рабочая группа по сетевым вопросам B. Thompson
Запрос комментариев: 4170 T. Koren
BCP: 110 D. Wing
Категория: Лучшая современная практика Cisco Systems
Ноябрь 2005
Туннелирование мультиплексированного сжатого RTP (TCRTP)
Статус данного меморандума
Этот документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение данного меморандума не ограничено.
Уведомление об авторских правах
Авторское право (C) The Internet Society (2005).
Аннотация
Этот документ описывает метод улучшения использования полосы пропускания
потоками RTP на сетевых путях, по которым параллельно между двумя конечными
точками передаются несколько потоков Real-time Transport Protocol (RTP),
как при транкинге голосового трафика. Метод объединяет стандартные
протоколы, обеспечивающие сжатие, мультиплексирование и туннелирование по
сетевому пути, с целью уменьшить используемую полосу пропускания при
передаче по этому пути нескольких потоков RTP.
Thompson и др. Лучшая современная практика [Страница 1]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
Содержание
1. Введение .......................................................3
1.1. Является ли полоса пропускания дорогостоящей? .............3
1.2. Обзор протоколов ..........................................3
1.3. Фокус документа ...........................................4
1.4. Выбор Enhanced CRTP .......................................4
1.5. Снижение накладных расходов TCRTP .........................4
2. Работа протоколов и рекомендуемые расширения ...................4
2.1. Модели ....................................................5
2.2. Сжатие заголовков: ECRTP .................................5
2.2.1. Синхронизация состояний ECRTP .....................5
2.2.2. Пакеты, поступившие не по порядку .................6
2.3. Мультиплексирование: PPP Multiplexing ....................6
2.3.1. Модификации передатчика PPP Multiplex для
туннелирования ....................................7
2.3.2. Неэффективности туннелирования ....................8
2.4. Туннелирование: L2TP .....................................8
2.4.1. Туннелирование и DiffServ ..........................9
2.5. Форматы инкапсуляции ......................................9
3. Эффективность использования полосы пропускания ................10
3.1. Выигрыш от мультиплексирования ...........................10
3.2. Уровень потерь пакетов ...................................10
3.3. Расчёт полосы пропускания для голосовых и видеоприложений 10
3.3.1. Пример расчёта полосы пропускания для голоса .....12
3.3.2. Таблица сравнения полосы пропускания для голоса ..13
3.3.3. Пример расчёта полосы пропускания для видео ......13
3.3.4. TCRTP поверх ATM ..................................14
3.3.5. TCRTP поверх сетей, не использующих ATM ..........14
4. Пример реализации TCRTP .......................................15
4.1. Предлагаемое согласование PPP и L2TP для TCRTP ...........17
4.2. Согласование PPP TCRTP ...................................17
4.2.1. Согласование LCP .................................17
4.2.2. Согласование IPCP ................................18
4.3. Согласование L2TP ........................................19
4.3.1. Установление туннеля .............................19
4.3.2. Установление сеанса ..............................19
4.3.3. Завершение туннеля ................................20
5. Вопросы безопасности ..........................................20
6. Благодарности .................................................21
7. Ссылки ........................................................21
7.1. Нормативные ссылки .......................................21
7.2. Информационные ссылки ....................................22
Thompson и др. Лучшая современная практика [Страница 2]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
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 не требует какой-либо
дополнительной обработки на каждом маршрутизаторе для достижения сжатия
заголовков. Вместо этого заголовки сжимаются между конечными точками, что
экономит полосу пропускания на всех промежуточных каналах.
Thompson и др. Лучшая современная практика [Страница 3]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
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.
Thompson и др. Лучшая современная практика [Страница 4]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
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 в декомпрессоре.
Thompson и др. Лучшая современная практика [Страница 5]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
Для обеспечения доставки обновлений переменных контекста пакеты
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.
Thompson и др. Лучшая современная практика [Страница 6]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
При установлении 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.
Thompson, et al. Лучшая современная практика [Страница 7]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
Когда выполнено любое из условий, мультиплексированная полезная нагрузка 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.
Thompson, et al. Лучшая современная практика [Страница 8]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
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».
Thompson, et al. Лучшая современная практика [Страница 9]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
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. Расчёт полосы пропускания для голосовых и видеоприложений
Следующая формула использует описанные выше факторы для моделирования
использования полосы пропускания на поток как для голосовых, так и для
видеоприложений. Определяются следующие переменные:
Thompson, et al. Лучшая современная практика [Страница 10]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
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 в октетах.
Thompson, et al. Лучшая современная практика [Страница 11]
RFC 4170 Туннелирование мультиплексированного сжатого RTP Ноябрь 2005
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 кбит/с.
Thompson, et al. Лучшая современная практика [Страница 12]
RFC 4170 Tunneling Multiplexed Compressed RTP Ноябрь 2005
Влияние 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 действительно обеспечивает некоторую экономию пропускной способности для видео, отношение заголовков передачи к полезной нагрузке настолько мало, что экономия пропускной способности незначительна.
Thompson, et al. Лучшая современная практика [Страница 13]
RFC 4170 Tunneling Multiplexed Compressed RTP Ноябрь 2005
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
Thompson, et al. Лучшая современная практика [Страница 14]
RFC 4170 Tunneling Multiplexed Compressed RTP Ноябрь 2005
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 в этой реализации:
Thompson, et al. Лучшая современная практика [Страница 15]
RFC 4170 Tunneling Multiplexed Compressed RTP Ноябрь 2005
+-------------------------------+ ^
| Приложение | |
+-------------------------------+ |
| 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 маршрутизируются в интерфейс туннеля, где заголовки сжимаются, полезные нагрузки мультиплексируются, а затем пакеты туннелируются к хосту назначения.
Thompson, et al. Лучшая современная практика [Страница 16]
RFC 4170 Tunneling Multiplexed Compressed RTP Ноябрь 2005
Работа принимающего узла аналогична работе передающего узла в обратном порядке.
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
Thompson, et al. Лучшая современная практика [Страница 17]
RFC 4170 Tunneling Multiplexed Compressed RTP Ноябрь 2005
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 ->
Thompson, et al. Лучшая современная практика [Страница 18]
RFC 4170 Tunneling Multiplexed Compressed RTP Ноябрь 2005
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
Thompson, et al. Лучшая современная практика [Страница 19]
RFC 4170 Tunneling Multiplexed Compressed RTP Ноябрь 2005
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], предоставляет
более
Thompson, et al. Best Current Practice [Page 20]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
совершенные и полные методы шифрования и аутентификации сообщений, чем
базовый подход в [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. Ссылки
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.
Thompson, et al. Best Current Practice [Page 21]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
[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.
Thompson, et al. Best Current Practice [Page 22]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
Адреса авторов
Bruce Thompson
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
Phone: +1 408 527 0446
EMail: brucet@cisco.com
Tmima Koren
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
Phone: +1 408 527 6169
EMail: tmima@cisco.com
Dan Wing
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
EMail: dwing@cisco.com
Thompson, et al. Best Current Practice [Page 23]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
Полное заявление об авторских правах
Copyright (C) The Internet Society (2005).
Настоящий документ подпадает под действие прав, лицензий и ограничений,
содержащихся в BCP 78, и, за исключением изложенного в нём, авторы
сохраняют все свои права.
Настоящий документ и содержащаяся в нём информация предоставляются на
условиях «КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА
ПРЕДСТАВЛЯЕТ ИЛИ КОТОРОЙ ОН/ОНА СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ),
INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ
ГАРАНТИЙ, ЯВНО ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, В ЧАСТНОСТИ,
ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ
НАРУШИТ КАКИЕ-ЛИБО ПРАВА, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ
ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма каких-
либо прав интеллектуальной собственности либо иных прав, которые могут
заявляться как относящиеся к реализации или использованию технологии,
описанной в настоящем документе, или относительно того, может ли или не
может быть доступна какая-либо лицензия по таким правам; также IETF не
заявляет, что предприняла какие-либо независимые усилия по выявлению
подобных прав. Информацию о процедурах, касающихся прав в документах RFC,
можно найти в BCP 78 и BCP 79.
Копии раскрытий IPR, направленных в Секретариат IETF, и любых заверений о
том, что лицензии будут доступны, либо результат попытки получить общую
лицензию или разрешение на использование таких прав собственности
разработчиками или пользователями этой спецификации можно получить из
онлайнового репозитория IPR IETF по адресу
http://www.ietf.org/ipr.
IETF приглашает любую заинтересованную сторону довести до её сведения
информацию о любых авторских правах, патентах или патентных заявках либо
иных правах собственности, которые могут охватывать технологию, которая
может потребоваться для реализации этого стандарта. Просьба направлять
информацию в IETF по адресу ietf-
ipr@ietf.org.
Благодарность
Финансирование функции RFC Editor в настоящее время обеспечивает
Internet Society.
Thompson, et al. Best Current Practice [Page 24]
Network Working Group B. Thompson
Request for Comments: 4170 T. Koren
BCP: 110 D. Wing
Category: Best Current Practice Cisco Systems
November 2005
Tunneling Multiplexed Compressed RTP (TCRTP)
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a method to improve the bandwidth utilization
of RTP streams over network paths that carry multiple Real-time
Transport Protocol (RTP) streams in parallel between two endpoints,
as in voice trunking. The method combines standard protocols that
provide compression, multiplexing, and tunneling over a network path
for the purpose of reducing the bandwidth used when multiple RTP
streams are carried over that path.
Thompson, et al. Best Current Practice [Page 1]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
Table of Contents
1. Introduction ....................................................3
1.1. Is Bandwidth Costly? .......................................3
1.2. Overview of Protocols ......................................3
1.3. Document Focus .............................................4
1.4. Choice of Enhanced CRTP ....................................4
1.5. Reducing TCRTP Overhead ....................................4
2. Protocol Operation and Recommended Extensions ...................4
2.1. Models .....................................................5
2.2. Header Compression: ECRTP ..................................5
2.2.1. Synchronizing ECRTP States ..........................5
2.2.2. Out-of-Order Packets ................................6
2.3. Multiplexing: PPP Multiplexing .............................6
2.3.1. PPP Multiplex Transmitter Modifications for
Tunneling ...........................................7
2.3.2. Tunneling Inefficiencies ............................8
2.4. Tunneling: L2TP ............................................8
2.4.1. Tunneling and DiffServ ..............................9
2.5. Encapsulation Formats ......................................9
3. Bandwidth Efficiency ...........................................10
3.1. Multiplexing Gains ........................................10
3.2. Packet Loss Rate ..........................................10
3.3. Bandwidth Calculation for Voice and Video Applications ....10
3.3.1. Voice Bandwidth Calculation Example ................12
3.3.2. Voice Bandwidth Comparison Table ...................13
3.3.3. Video Bandwidth Calculation Example ................13
3.3.4. TCRTP over ATM .....................................14
3.3.5. TCRTP over Non-ATM Networks ........................14
4. Example Implementation of TCRTP ................................15
4.1. Suggested PPP and L2TP Negotiation for TCRTP ..............17
4.2. PPP Negotiation TCRTP .....................................17
4.2.1. LCP Negotiation ....................................17
4.2.2. IPCP Negotiation ...................................18
4.3. L2TP Negotiation ..........................................19
4.3.1. Tunnel Establishment ...............................19
4.3.2. Session Establishment ..............................19
4.3.3. Tunnel Tear Down ...................................20
5. Security Considerations ........................................20
6. Acknowledgements ...............................................21
7. References .....................................................21
7.1. Normative References ......................................21
7.2. Informative References ....................................22
Thompson, et al. Best Current Practice [Page 2]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
1. Introduction
This document describes a way to combine existing protocols for
compression, multiplexing, and tunneling to save bandwidth for some
RTP applications.
1.1. Is Bandwidth Costly?
On certain links, such as customer access links, the cost of
bandwidth is widely acknowledged to be a significant concern.
protocols such as CRTP (Compressed RTP, [CRTP]) are well suited to
help bandwidth inefficiencies of protocols such as VoIP over these
links.
Unacknowledged by many, however, is the cost of long-distance WAN
links. While some voice-over-packet technologies such as Voice over
ATM (VoAAL2, [I.363.2]) and Voice over MPLS provide bandwidth
efficiencies (because both technologies lack IP, UDP, and RTP
headers), neither VoATM nor VoMPLS provide direct access to voice-
over-packet services available to Voice over IP. Thus, goals of WAN
link cost reduction are met at the expense of lost interconnection
opportunities to other networks.
TCRTP solves the VoIP bandwidth discrepancy, especially for large,
voice-trunking applications.
1.2. Overview of Protocols
Header compression is accomplished using Enhanced CRTP (ECRTP,
[ECRTP]). ECRTP is an enhancement to classical CRTP [CRTP] that
works better over long delay links, such as the end-to-end tunneling
links described in this document. This header compression reduces
the IP, UDP, and RTP headers.
Multiplexing is accomplished using PPP Multiplexing [PPP-MUX].
Tunneling PPP is accomplished by using L2TP [L2TPv3].
CRTP operates link-by-link; that is, to achieve compression over
multiple router hops, CRTP must be employed twice on each router --
once on ingress, again on egress. In contrast, TCRTP described in
this document does not require any additional per-router processing
to achieve header compression. Instead, headers are compressed end-
to-end, saving bandwidth on all intermediate links.
Thompson, et al. Best Current Practice [Page 3]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
1.3. Document Focus
This document is primarily concerned with bandwidth savings for Voice
over IP (VoIP) applications over high-delay networks. However, the
combinations of protocols described in this document can be used to
provide similar bandwidth savings for other RTP applications such as
video, and bandwidth savings are included for a sample video
application.
1.4. Choice of Enhanced CRTP
CRTP [CRTP] describes the use of RTP header compression on an
unspecified link layer transport, but typically PPP is used. For
CRTP to compress headers, it must be implemented on each PPP link. A
lot of context is required to successfully run CRTP, and memory and
processing requirements are high, especially if multiple hops must
implement CRTP to save bandwidth on each of the hops. At higher line
rates, CRTP's processor consumption becomes prohibitively expensive.
To avoid the per-hop expense of CRTP, a simplistic solution is to use
CRTP with L2TP to achieve end-to-end CRTP. However, as described in
[ECRTP], CRTP is only suitable for links with low delay and low loss.
However, once multiple router hops are involved, CRTP's expectation
of low delay and low loss can no longer be met. Further, packets can
arrive out of order.
Therefore, this document describes the use of Enhanced CRTP [ECRTP],
which supports high delay, both packet loss, and misordering between
the compressor and decompressor.
1.5. Reducing TCRTP Overhead
If only one stream is tunneled (L2TP) and compressed (ECRTP), there
are little bandwidth savings. Multiplexing is helpful to amortize
the overhead of the tunnel header over many RTP payloads. The
multiplexing format proposed by this document is PPP multiplexing
[PPP-MUX]. See Section 2.3 for details.
2. Protocol Operation and Recommended Extensions
This section describes how to combine three protocols: Enhanced CRTP,
PPP Multiplexing, and L2TP Tunneling, to save bandwidth for RTP
applications such as Voice over IP.
Thompson, et al. Best Current Practice [Page 4]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
2.1. Models
TCRTP can typically be implemented in two ways. The most
straightforward is to implement TCRTP in the gateways terminating the
RTP streams:
[voice gateway]---[voice gateway]
^
|
TCRTP over IP
Another way TCRTP can be implemented is with an external
concentration device. This device could be placed at strategic
places in the network and could dynamically create and destroy TCRTP
sessions without the participation of RTP-generating endpoints.
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
RTP over IP TCRTP over IP RTP over IP
Such a design also allows classical CRTP [CRTP] to be used on links
with only a few active flows per link (where TCRTP isn't efficient;
see Section 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. Header Compression: ECRTP
As described in [ECRTP], classical CRTP [CRTP] is not suitable over
long-delay WAN links commonly used when tunneling, as proposed by
this document. Thus, ECRTP should be used instead of CRTP.
2.2.1. Synchronizing ECRTP States
When the compressor receives an RTP packet that has an unpredicted
change in the RTP header, the compressor should send a COMPRESSED_UDP
packet (described in [ECRTP]) to synchronize the ECRTP decompressor
state. The COMPRESSED_UDP packet updates the RTP context in the
decompressor.
Thompson, et al. Best Current Practice [Page 5]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
To ensure delivery of updates of context variables, COMPRESSED_UDP
packets should be delivered using the robust operation described in
[ECRTP].
Because the "twice" algorithm described in [ECRTP] relies on UDP
checksums, the IP stack on the RTP transmitter should transmit UDP
checksums. If UDP checksums are not used, the ECRTP compressor
should use the CRTP Headers checksum described in [ECRTP].
2.2.2. Out-of-Order Packets
Tunneled transport does not guarantee ordered delivery of packets.
Therefore, the ECRTP decompressor must operate correctly in the
presence of out of order packets.
The order of packets for RTP is determined by the RTP sequence
number. To add robustness in case of packet loss or packet
reordering, ECRTP sends short deltas together with the full value
when updating context variables, and repeats the updates in N
packets, where N is an engineered constant tuned to the kind of pipe
ECRTP is used for.
By contrast, [ROHC] compresses out the sequence number and another
layer is necessary for [ROHC] to handle out-of-order delivery of
packets over a tunnel [REORDER].
2.3. Multiplexing: PPP Multiplexing
Both CRTP and ECRTP require a layer two protocol that allows
identifying different protocols. [PPP] is suited for this.
When CRTP is used inside of a tunnel, the header compression
associated with CRTP will reduce the size of the IP, UDP, and IP
headers of the IP packet carried in the tunnel. However, the tunnel
itself has overhead due to its IP header and the tunnel header (the
information necessary to identify the tunneled payload). One way to
reduce the overhead of the IP header and tunnel header is to
multiplex multiple RTP payloads in a single tunneled packet.
[PPP-MUX] describes an encapsulation that combines multiple PPP
payloads into one multiplexed payload. PPP multiplexing allows any
supported PPP payload type to be multiplexed. This multiplexed frame
is then carried as a single PPPMUX payload in the IP tunnel. This
allows multiple RTP payloads to be carried in a single IP tunnel
packet and allows the overhead of the uncompressed IP and tunnel
headers to be amortized over multiple RTP payloads.
Thompson, et al. Best Current Practice [Page 6]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
During PPP establishment of the TCRTP tunnel, only LCP and IPCP (for
header compression) are required -- IP addresses do not need to be
negotiated, nor is authentication necessary. See Section 4.1 for
details.
2.3.1. PPP Multiplex Transmitter Modifications for Tunneling
Section 1.2 of [PPP-MUX] describes an example transmitter procedure
that can be used to implement a PPP Multiplex transmitter. The
transmission procedure described in this section includes a parameter
MAX-SF-LEN that is used to limit the maximum size of a PPP Multiplex
frame.
There are two reasons for limiting the size of a PPP Multiplex frame.
First, a PPPMUX frame should never exceed the Maximum Receive Unit
(MRU) of a physical link. Second, when a PPP session and its
associated flow control are bound to a physical link, the MAX-SF-LEN
parameter forms an upper limit on the amount of time a multiplex
packet can be held before being transmitted. When flow control for
the PPP Multiplex transmitter is bound to a physical link, the clock
rate of the physical link can be used to pull frames from the PPP
Multiplex transmitter.
This type of flow control limits the maximum amount of time a PPP
multiplex frame can be held before being transmitted to MAX-SF-LEN /
Link Speed.
Tunnel interfaces are typically not bound to physical interfaces.
Because of this, a tunnel interface has no well-known transmission
rate associated with it. This means that flow control in the PPPMUX
transmitter cannot rely on the clock of a physical link to pull
frames from the multiplex transmitter. Instead, a timer must be used
to limit the amount of time a PPPMUX frame can be held before being
transmitted. The timer along with the MAX-SF-LEN parameter should be
used to limit the amount of time a PPPMUX frame is held before being
transmitted.
The following extensions to the PPPMUX transmitter logic should be
made for use with tunnels. The flow control logic of the PPP
transmitter should be modified to collect incoming payloads until one
of two events has occurred:
(1) a specific number of octets, MAX-SF-LEN, has arrived at
the multiplexer, or
(2) a timer, called T, has expired.
Thompson, et al. Best Current Practice [Page 7]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
When either condition is satisfied, the multiplexed PPP payload is
transmitted.
The purpose of MAX-SF-LEN is to ensure that a PPPMUX payload does not
exceed the MTU size of any of the possible physical links that the
tunnel can be associated with. The value of MAX-SF-LEN should be
less than or equal to the minimum of MRU-2 (maximum size of length
field) and 16,383 (14 bits) for all possible physical interfaces that
the tunnel may be associated with.
The timer T provides an upper delay bound for tunnel interfaces.
Timer T is reset whenever a multiplexed payload is sent to the next
encapsulation layer. The behavior of this timer is similar to AAL2's
Timer_CU described in [I.363.2]. Each PPPMUX transmitter should have
its own Timer T.
The optimal values for T will vary depending upon the rate at which
payloads are expected to arrive at the multiplexer and the delay
budget for the multiplexing function. For voice applications, the
value of T would typically be 5-10 milliseconds.
2.3.2. Tunneling Inefficiencies
To get reasonable bandwidth efficiency using multiplexing within an
L2TP tunnel, multiple RTP streams should be active between the source
and destination of an L2TP tunnel.
If the source and destination of the L2TP tunnel are the same as the
source and destination of the ECRTP sessions, then the source and
destination must have multiple active RTP streams to get any benefit
from multiplexing.
Because of this limitation, TCRTP is mostly useful for applications
where many RTP sessions run between a pair of RTP endpoints. The
number of simultaneous RTP sessions required to reduce the header
overhead to the desired level depends on the size of the L2TP header.
A smaller L2TP header will result in fewer simultaneous RTP sessions
being required to produce bandwidth efficiencies similar to CRTP.
2.4. Tunneling: L2TP
L2TP tunnels should be used to tunnel the ECRTP payloads end to end.
L2TP includes methods for tunneling messages used in PPP session
establishment, such as NCP. This allows [IPCP-HC] to negotiate ECRTP
compression/decompression parameters.
Thompson, et al. Best Current Practice [Page 8]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
2.4.1. Tunneling and DiffServ
RTP streams may be marked with Expedited Forwarding (EF) bits, as
described in [EF-PHB]. When such a packet is tunneled, the tunnel
header must also be marked for the same EF bits, as required by
[EF-PHB]. It is important to not mix EF and non-EF traffic in the
same EF-marked multiplexed tunnel.
2.5. Encapsulation Formats
The packet format for an RTP packet, compressed with RTP header
compression as defined in ECRTP, is:
+---------+---------+-------------+-----------------------+
| | MSTI | | |
| Context | | UDP | |
| ID | Link | Checksum | RTP Data |
| | Sequence| | |
| (1-2) | (1) | (0-2) | |
+---------+---------+-------------+-----------------------+
The packet format of a multiplexed PPP packet as defined by [PPP-MUX]
is:
+-------+---+------+-------+-----+ +---+------+-------+-----+
| 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) | |
+-------+----------+-------+-----+ +----------+-------+-----+
The combined format used for TCRTP with a single payload is all of
the above packets concatenated. Here is an example with one payload:
+------+-------+----------+-------+-------+-----+-------+----+
| 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 --------------------->|
If the tunnel contains multiplexed traffic, multiple "PPPMux
payload"s are transmitted in one IP packet.
Thompson, et al. Best Current Practice [Page 9]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
3. Bandwidth Efficiency
The expected bandwidth efficiency attainable with TCRTP depends upon
a number of factors. These factors include multiplexing gain,
expected packet loss rate across the network, and rates of change of
specific fields within the IP and RTP headers. This section also
describes how TCRTP significantly enhances bandwidth efficiency for
voice over IP over ATM.
3.1. Multiplexing Gains
Multiplexing reduces the overhead associated with the layer 2 and
tunnel headers. Increasing the number of CRTP payloads combined into
one multiplexed PPP payload increases multiplexing gain. As traffic
increases within a tunnel, more payloads are combined in one
multiplexed payload. This will increase multiplexing gain.
3.2. Packet Loss Rate
Loss of a multiplexed packet causes packet loss for all of the flows
within the multiplexed packet.
When the expected loss rate in a tunnel is relatively low (less than
perhaps 5%), the robust operation (described in [ECRTP]) should be
sufficient to ensure delivery of state changes. This robust
operation is characterized by a parameter N, which means that the
probability of more than N adjacent packets getting lost on the
tunnel is small.
A value of N=1 will protect against the loss of a single packet
within a compressed session, at the expense of bandwidth. A value of
N=2 will protect against the loss of two packets in a row within a
compressed session and so on. Higher values of N have higher
bandwidth penalties.
The optimal value of N will depend on the loss rate in the tunnel.
If the loss rate is high (above perhaps 5%), more advanced techniques
must be employed. Those techniques are beyond the scope of this
document.
3.3. Bandwidth Calculation for Voice and Video Applications
The following formula uses the factors described above to model per-
flow bandwidth usage for both voice and video applications. These
variables are defined:
Thompson, et al. Best Current Practice [Page 10]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
SOV-TCRTP, unit: octet. Per-payload overhead of ECRTP and the
multiplexed PPP header. This value does not include
additional overhead for updating IP ID or the RTP Time Stamp
fields (see [ECRTP] for details on IP ID). The value assumes
the use of the COMPRESSED_RTP payload type. It consists of 1
octet for the ECRTP context ID, 1 octet for COMPRESSED_RTP
flags, 2 octets for the UDP checksum, 1 octet for PPP protocol
ID, and 1 octet for the multiplexed PPP length field. The
total is 6 octets.
POV-TCRTP, unit: octet. Per-packet overhead of tunneled ECRTP. This
is the overhead for the tunnel header and the multiplexed PPP
payload type. This value is 20 octets for the IP header, 4
octets for the L2TPv3 header and 1 octet for the multiplexed
PPP protocol ID. The total is 25 octets.
TRANSMIT-LENGTH, unit: milliseconds. The average duration of a
transmission (such as a talk spurt for voice streams).
SOV-TSTAMP, unit: octet. Additional per-payload overhead of the
COMPRESSED_UDP header that includes the absolute time stamp
field. This value includes 1 octet for the extra flags field
in the COMPRESSED_UDP header and 4 octets for the absolute
time stamp, for a total of 5 octets.
SOV-IPID, unit: octet. Additional per-payload overhead of the
COMPRESSED_UDP header that includes the absolute IPID field.
This value includes 2 octets for the absolute IPID. This
value also includes 1 octet for the extra flags field in the
COMPRESSED_UDP header. The total is 3 octets.
IPID-RATIO, unit: integer values 0 or 1. Indicates the frequency at
which IPID will be updated by the compressor. If IPID is
changing randomly and thus always needs to be updated, then
the value is 1. If IPID is changing by a fixed constant
amount between payloads of a flow, then IPID-RATIO will be 0.
The value of this variable does not consider the IPID value at
the beginning of a voice or video transmission, as that is
considered by the variable TRANSMIT-LENGTH. The
implementation of the sending IP stack and RTP application
controls this behavior. See Section 1.1.
NREP, unit: integer (usually a number between 1 and 3). This is the
number of times an update field will be repeated in ECRTP
headers to increase the delivery rate between the compressor
and decompressor. For this example, we will assume NREP=2.
PAYLOAD-SIZE, unit: octets. The size of the RTP payload in octets.
Thompson, et al. Best Current Practice [Page 11]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
MUX-SIZE, unit: count. The number of PPP payloads multiplexed into
one multiplexed PPP payload.
SAMPLE-PERIOD, unit: milliseconds. The average delay between
transmissions of voice or video payloads for each flow in the
multiplex. For example, in voice applications the value of
this variable would be 10ms if all calls have a 10ms sample
period.
The formula is:
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)
The results are:
BANDWIDTH, unit: kilobits per second. The average amount of
bandwidth used per voice or video flow.
SOV-TOTAL = The total amount of per-payload overhead associated
with tunneled ECRTP. It includes the per-payload
overhead of ECRTP and PPP, timestamp update overhead,
and IPID update overhead.
3.3.1. Voice Bandwidth Calculation Example
To create an example for a voice application using the above
formulas, we will assume the following usage scenario. Compressed
voice streams using G.729 compression with a 20 millisecond
packetization period. In this scenario, VAD is enabled and the
average talk spurt length is 1500 milliseconds. The IPID field is
changing randomly between payloads of streams. There is enough
traffic in the tunnel to allow 3 multiplexed payloads. The following
values apply:
SAMPLE-PERIOD = 20 milliseconds
TRANSMIT-LENGTH = 1500 milliseconds
IPID-RATIO = 1
PAYLOAD-SIZE = 20 octets
MUX-SIZE = 3
For this example, per call bandwidth is 16.4 kbits/sec. Classical
CRTP over a single HDLC link using the same factors as above yields
12.4 kbits/sec.
Thompson, et al. Best Current Practice [Page 12]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
The effect of IPID can have a large effect on per call bandwidth. If
the above example is recalculated using an IPID-RATIO of 0, then the
per call bandwidth is reduced to 13.8 kbits/sec. Classical CRTP over
a single HDLC link, using these same factors, yields 11.2 kbits/call.
3.3.2. Voice Bandwidth Comparison Table
The bandwidth values are as follows when using 5 simultaneous calls,
no voice activity detection (VAD), G.729 with 20ms packetization
interval, and not considering RTCP overhead:
Normal VoIP over PPP: 124 kbps
with classical CRTP on a link: 50 kbps (savings: 59%)
with TCRTP over PPP: 62 kbps (savings: 50%)
with TCRTP over AAL5: 85 kbps (savings: 31%)
3.3.3. Video Bandwidth Calculation Example
Since TCRTP can be used to save bandwidth on any type of RTP
encapsulated flow, it can be used to save bandwidth for video
applications. This section documents an example of TCRTP-based
bandwidth savings for MPEG-2 encoded video.
To create an example for a video application using the above
formulas, we will assume the following usage scenario. RTP
encapsulation of MPEG System and Transport Streams is performed as
described in RFC 2250. Frames for MPEG-2 encoded video are sent
continuously, so the TRANSMIT-LENGTH variable in the bandwidth
formula is essentially infinite. The IPID field is changing randomly
between payloads of streams. There is enough traffic in the tunnel
to allow 3 multiplexed payloads. The following values apply:
SAMPLE-PERIOD = 2.8 milliseconds
TRANSMIT-LENGTH = infinite
IPID-RATIO = 1
PAYLOAD-SIZE = 1316 octets
MUX-SIZE = 3
For this example, per flow bandwidth is 3.8 Mbits/sec. MPEG video
with no header compression, using the same factors as above, yields
3.9 Mbits/sec. While TCRTP does provide some bandwidth savings for
video, the ratio of transmission headers to payload is so small that
the bandwidth savings are insignificant.
Thompson, et al. Best Current Practice [Page 13]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
3.3.4. TCRTP over ATM
IP transport over AAL5 causes a quantizing effect on bandwidth
utilization due to the packets always being multiples of ATM cells.
For example, the payload size for G.729 using 10 millisecond
packetization intervals is 10 octets. This is much smaller than the
payload size of an ATM cell (48 octets). When classical CRTP [CRTP]
is used on a link-by-link basis, the IP overhead to payload ratio is
quite good. However, AAL5 encapsulation and its cell padding always
force the minimum payload size to be one ATM cell, which results in
poor bandwidth utilization.
Instead of wasting this padding, the multiplexing of TCRTP allows
this previously wasted space in the ATM cell to contain useful data.
This is one of the main reasons why multiplexing has such a large
effect on bandwidth utilization with Voice over IP over ATM.
This multiplexing efficiency of TCRTP is similar to AAL2 sub-cell
multiplexing described in [I.363.2]. Unlike AAL2 sub-cell
multiplexing, however, TCRTP's multiplexing efficiency isn't limited
to only ATM networks.
3.3.5. TCRTP over Non-ATM Networks
When TCRTP is used with other layer 2 encapsulations that do not have
a minimum PDU size, the benefit of multiplexing is not as great.
Depending upon the exact overhead of the layer 2 encapsulation, the
benefit of multiplexing might be slightly better or worse than link-
by-link CRTP header compression. The per-payload overhead of CRTP
tunneling is either 4 or 6 octets. If classical CRTP plus layer 2
overhead is greater than this amount, TCRTP multiplexing will consume
less bandwidth than classical CRTP when the outer IP header is
amortized over a large number of payloads.
The payload breakeven point can be determined by the following
formula:
POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX + SOV-PPPMUX
* MUX-SIZE
Where:
POV-L2, unit: octet. Layer 2 packet overhead: 5 octets for HDLC
encapsulation
Thompson, et al. Best Current Practice [Page 14]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
POV-TUNNEL, unit: octet. Packet overhead due to tunneling: 24
octets IP header and L2TPv3 header
POV-PPPMUX, unit: octet. Packet overhead for the multiplexed PPP
protocol ID: 1 octet
SOV-PPPMUX, unit: octet. Per-payload overhead of PPPMUX, which is
comprised of the payload length field and the ECRTP protocol
ID. The value of SOV-PPPMUX is typically 1, 2, or 3.
If using HDLC as the layer 2 protocol, the breakeven point (using the
above formula) is when MUX-SIZE = 7. Thus 7 voice or video flows
need to be multiplexed to make TCRTP as bandwidth-efficient as link-
by-link CRTP compression.
4. Example Implementation of TCRTP
This section describes an example implementation of TCRTP.
Implementations of TCRTP may be done in many ways as long as the
requirements of the associated RFCs are met.
Here is the path an RTP packet takes in this implementation:
Thompson, et al. Best Current Practice [Page 15]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
+-------------------------------+ ^
| Application | |
+-------------------------------+ |
| RTP | |
+-------------------------------+ Application and
| UDP | IP stack
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| IP forwarding
|
+-------------------------------+ ^
| ECRTP | |
+-------------------------------+ |
| PPPMUX | |
+-------------------------------+ Tunnel
| PPP | Interface
+-------------------------------+ |
| L2TP | |
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| IP forwarding
|
+-------------------------------+ ^
| Layer 2 | |
+-------------------------------+ Physical
| Physical | Interface
+-------------------------------+ V
A protocol stack is configured to create an L2TP tunnel interface to
a destination host. The tunnel is configured to negotiate the PPP
connection (using NCP IPCP) with ECRTP header compression and PPPMUX.
IP forwarding is configured to route RTP packets to this tunnel. The
destination UDP port number could distinguish RTP packets from non-
RTP packets.
The transmitting application gathers the RTP data from one source,
and formats an RTP packet. Lower level application layers add UDP
and IP headers to form a complete IP packet.
The RTP packets are routed to the tunnel interface where headers are
compressed, payloads are multiplexed, and then the packets are
tunneled to the destination host.
Thompson, et al. Best Current Practice [Page 16]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
The operation of the receiving node is the same as the transmitting
node in reverse.
4.1. Suggested PPP and L2TP Negotiation for TCRTP
This section describes the necessary PPP and LT2P negotiations
necessary for establishing a PPP connection and L2TP tunnel with L2TP
header compression. The negotiation is between two peers: Peer1 and
Peer2.
4.2. PPP Negotiation TCRTP
The Point-to-Point Protocol is described in [PPP].
4.2.1. LCP Negotiation
Link Control Processing (LCP) is described in [PPP].
4.2.1.1. Link Establishment
Peer1 Peer2
----- -----
Configure-Request (no options) ->
<- Configure-Ack
<- Configure-Request (no options)
Configure-Ack ->
4.2.1.2. Link Tear Down
Terminate-Request ->
<- Terminate-Ack
Thompson, et al. Best Current Practice [Page 17]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
4.2.2. IPCP Negotiation
The protocol exchange here is described in [IPHCOMP], [PPP], and
[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 ->
Thompson, et al. Best Current Practice [Page 18]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
4.3. L2TP Negotiation
L2TP is described in [L2TPv3].
4.3.1. Tunnel Establishment
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. Session Establishment
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
Thompson, et al. Best Current Practice [Page 19]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
4.3.3. Tunnel Tear Down
Peer1 Peer2
----- -----
StopCCN ->
Mandatory AVP's:
Message Type
Assigned Tunnel ID
Result Code
<- ZLB
5. Security Considerations
This document describes a method for combining several existing
protocols that implement compression, multiplexing, and tunneling of
RTP streams. Attacks on the component technologies of TCRTP include
attacks on RTP/RTCP headers and payloads carried within a TCRTP
session, attacks on the compressed headers, attacks on the
multiplexing layer, or attacks on the tunneling negotiation or
transport. The security issues associated individually with each of
those component technologies are addressed in their respective
specifications, [ECRTP], [PPP-MUX], [L2TPv3], along with the security
considerations for RTP itself [RTP].
However, there may be additional security considerations arising from
the use of these component technologies together. For example, there
may be an increased risk of unintended misdelivery of packets from
one stream in the multiplex to another due to a protocol malfunction
or data error because the addressing information is more condensed.
This is particularly true if the tunnel is transmitted over a link-
layer protocol that allows delivery of packets containing bit errors,
in combination with a tunnel transport layer option that does not
checksum all of the payload.
The opportunity for malicious misdirection may be increased, relative
to that for a single RTP stream transported by itself, because
addressing information must be unencrypted for the header compression
and multiplexing layers to function.
The primary defense against misdelivery is to make the data unusable
to unintended recipients through cryptographic techniques. The basic
method for encryption provided in the RTP specification [RTP] is not
suitable because it encrypts the RTP and RTCP headers along with the
payload. However, the RTP specification also allows alternative
approaches to be defined in separate profile or payload format
specifications wherein only the payload portion of the packet would
be encrypted; therefore, header compression may be applied to the
encrypted packets. One such profile, [SRTP], provides more
Thompson, et al. Best Current Practice [Page 20]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
sophisticated and complete methods for encryption and message
authentication than the basic approach in [RTP]. Additional methods
may be developed in the future. Appropriate cryptographic protection
should be incorporated into all TCRTP applications.
6. Acknowledgements
The authors would like to thank the authors of RFC 2508, Stephen
Casner and Van Jacobson, and the authors of RFC 2507, Mikael
Degermark, Bjorn Nordgren, and Stephen Pink.
The authors would also like to thank 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, and
Shoou Yiu.
7. References
7.1. Normative References
[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.
Thompson, et al. Best Current Practice [Page 21]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
[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. Informative References
[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.
Thompson, et al. Best Current Practice [Page 22]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
Authors' Addresses
Bruce Thompson
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
Phone: +1 408 527 0446
EMail: brucet@cisco.com
Tmima Koren
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
Phone: +1 408 527 6169
EMail: tmima@cisco.com
Dan Wing
170 West Tasman Drive
San Jose, CA 95134-1706
United States of America
EMail: dwing@cisco.com
Thompson, et al. Best Current Practice [Page 23]
RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Thompson, et al. Best Current Practice [Page 24]