RFC 4170
Tunneling Multiplexed Compressed RTP (TCRTP)
Tunneling Multiplexed Compressed RTP (TCRTP) 💖
Part 1 of 5 ✨
Okay bestie, here's the title block. This is RFC 4170, titled Tunneling Multiplexed Compressed RTP (TCRTP), and it's a Best Current Practice (BCP 110) 🎀. It was published in November 2005 and written by B. Thompson, T. Koren, and D. Wing, all from Cisco Systems 🦋. The header doesn't list any documents it obsoletes or updates, so there's nothing to chase there 💅.
Status of This Memo 📜
This document is an Internet Best Current Practices document for the Internet Community 🌸. It asks for discussion and suggestions for improvements, and the memo can be distributed as much as you want (unlimited!) 💜.
Copyright Notice 🔐
Copyright (C) The Internet Society (2005). 🌈
Abstract ✨
This doc is about making RTP streams use less bandwidth 🫶. It's for network paths that carry multiple RTP streams in parallel between two endpoints, like voice trunking 📞. The method mixes standard protocols that handle compression, multiplexing, and tunneling over a network path, all to cut down on the bandwidth those RTP streams use 🔥.
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 ....................................221. Introduction 🎀
This doc is about mixing existing protocols for compression, multiplexing, and tunneling so you can save bandwidth on some RTP apps 💅.
1.1. Is Bandwidth Costly? 💸
Okay so on certain links, like customer access links, bandwidth cost is a huge deal 😭. Stuff like CRTP (Compressed RTP, [CRTP]) is great at fixing the bandwidth waste that protocols like VoIP cause on these links 🌸.
But here's the thing people forget: long-distance WAN links cost a lot too 🙈. Voice over ATM (VoAAL2, [I.363.2]) and Voice over MPLS are efficient with bandwidth because neither one has IP, UDP, or RTP headers 🦋. The tea, though? Neither VoATM nor VoMPLS gives you direct access to the voice-over-packet services that Voice over IP has. So cutting WAN costs ends up costing you the chance to interconnect with other networks 💀.
TCRTP fixes the VoIP bandwidth gap, especially for big voice-trunking setups 👑.
1.2. Overview of Protocols 🧚
Header compression is done with Enhanced CRTP (ECRTP, [ECRTP]) 💜. ECRTP is an upgrade to classical CRTP [CRTP] that works better on long-delay links, like the end-to-end tunneling links this doc describes ✨. This compression shrinks the IP, UDP, and RTP headers 🍓.
Multiplexing is done with PPP Multiplexing [PPP-MUX] 🌈.
Tunneling PPP is done with L2TP [L2TPv3] 🫶.
Here's where CRTP is kinda lowkey annoying: it works link-by-link 🙄. To compress over multiple router hops, you have to run CRTP twice on each router, once on ingress and again on egress 💅. TCRTP is way more iconic. It doesn't need any extra per-router processing to compress headers. Instead, the headers get compressed end-to-end, which saves bandwidth on all the intermediate links too 🦋✨.
1.3. Document Focus 🔍
This doc is mainly about saving bandwidth for Voice over IP (VoIP) apps over high-delay networks 📞. The protocol combos here can also save bandwidth for other RTP apps, like video, and the doc includes bandwidth savings for a sample video app 🎥💖.
1.4. Choice of Enhanced CRTP 🤔
CRTP [CRTP] describes RTP header compression over an unspecified link layer transport, but PPP is what people usually use 🌸. For CRTP to compress headers, it has to run on each PPP link 😩. CRTP needs a LOT of context, and it eats memory and processing, especially if several hops all have to run CRTP to save bandwidth on each one 💀. At higher line rates, CRTP's processor consumption gets prohibitively expensive 🔥.
So to dodge the per-hop cost, the simple idea is to run CRTP with L2TP for end-to-end CRTP 💡. But as [ECRTP] explains, CRTP only works on links with low delay and low loss 🙈. Once multiple router hops are involved, CRTP can't keep that low-delay, low-loss promise anymore 😭. On top of that, packets can arrive out of order 🌀.
That's why this doc uses Enhanced CRTP [ECRTP], which handles high delay, packet loss, and misordering between the compressor and decompressor 👑✨.
1.5. Reducing TCRTP Overhead 📉
If only one stream gets tunneled (L2TP) and compressed (ECRTP), the bandwidth savings are pretty tiny 😬. Multiplexing helps spread the tunnel header's overhead across lots of RTP payloads 🦋. The multiplexing format this doc proposes is PPP multiplexing [PPP-MUX]. See Section 2.3 for the details 💜.
2. Protocol Operation and Recommended Extensions 🌟
This section explains how to combine three protocols, Enhanced CRTP, PPP Multiplexing, and L2TP Tunneling, to save bandwidth on RTP apps like Voice over IP 📞💖.
2.1. Models 🧩
TCRTP can usually be done in two ways 🎀. The most straightforward option is to implement TCRTP in the gateways that terminate the RTP streams 💅:
[voice gateway]---[voice gateway]
^
|
TCRTP over IPThe other way is to use an external concentration device 🌈. This device could sit at strategic spots in the network and dynamically create and destroy TCRTP sessions without the RTP-generating endpoints needing to take part 🦋.
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
RTP over IP TCRTP over IP RTP over IPThis design also lets classical CRTP [CRTP] be used on links with only a few active flows per link 🥺. (TCRTP isn't efficient in that case. 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 IP2.2. Header Compression: ECRTP 🗜️
As [ECRTP] explains, classical CRTP [CRTP] doesn't work well over the long-delay WAN links that you typically tunnel over, which is what this doc proposes 😩. So ECRTP should be used instead of CRTP 💖.
2.2.1. Synchronizing ECRTP States 🔄
Here's the vibe: when the compressor gets an RTP packet with an unpredicted change in the RTP header, the compressor should send a COMPRESSED_UDP packet (described in [ECRTP]) to sync the ECRTP decompressor state 🫶. The COMPRESSED_UDP packet updates the RTP context in the decompressor ✨.
To make sure context variable updates actually arrive, COMPRESSED_UDP packets should be delivered using the robust operation described in [ECRTP] 🛡️.
Also, the "twice" algorithm in [ECRTP] relies on UDP checksums, so the IP stack on the RTP transmitter should transmit UDP checksums 🔥. If UDP checksums aren't 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 😭. That means the ECRTP decompressor must operate correctly even when packets arrive out of order 👑.
The order of RTP packets is set by the RTP sequence number 🔢. To make things more robust when packets get lost or reordered, ECRTP sends short deltas together with the full value when it updates context variables. It also repeats the updates across N packets, where N is an engineered constant tuned to the kind of pipe ECRTP is used on 🦋✨.
By contrast, [ROHC] compresses out the sequence number, so another layer is needed for [ROHC] to handle out-of-order delivery of packets over a tunnel [REORDER] 🙈💜.
2.3. Multiplexing: PPP Multiplexing ✨
okay so both CRTP and ECRTP need a layer two protocol that can tell different protocols apart 🎀 and [PPP] is perfect for this bestie 💖
when CRTP runs inside a tunnel, it squishes down the IP, UDP, and IP headers of the IP packet riding in the tunnel 🦋 but the tunnel itself still has overhead from its own IP header and tunnel header (the stuff that says what the tunneled payload is) 🥺 so one way to shrink that extra overhead is to multiplex a bunch of RTP payloads into a single tunneled packet ✨
[PPP-MUX] describes an encapsulation that squashes multiple PPP payloads into one multiplexed payload 🧚 PPP multiplexing lets any supported PPP payload type get multiplexed, and the multiplexed frame then rides along as a single PPPMUX payload in the IP tunnel 💅 so multiple RTP payloads fit in one IP tunnel packet and the overhead of the uncompressed IP and tunnel headers gets spread across all of them 👑
during PPP establishment of the TCRTP tunnel, only LCP and IPCP (for header compression) are required 💜 IP addresses don't need to be negotiated and authentication isn't necessary 🙈 see Section 4.1 for the deets 🌸
2.3.1. PPP Multiplex Transmitter Modifications for Tunneling 🌈
Section 1.2 of [PPP-MUX] describes an example transmitter procedure you can use to build a PPP Multiplex transmitter 🎀 the transmission procedure in this section has a parameter called MAX-SF-LEN that caps how big a PPP Multiplex frame can get 💖
so there are two reasons we limit 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 flow control are bound to a physical link, MAX-SF-LEN sets the upper limit on how long a multiplex packet can get held before it's sent 🔥 when flow control for the PPP Multiplex transmitter is tied to a physical link, the clock rate of that link can be used to pull frames out of the PPP Multiplex transmitter ⭐
this kind of flow control limits how long a PPP multiplex frame can be held before it's transmitted to MAX-SF-LEN / Link Speed 🦋
tunnel interfaces usually aren't bound to physical interfaces 💀 which means a tunnel interface doesn't have a well-known transmission rate 😳 so flow control in the PPPMUX transmitter can't rely on a physical link's clock to pull frames out of the multiplex transmitter 🥹 instead, a timer has to be used to limit how long a PPPMUX frame can be held before it's 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 happened:
- (1) a specific number of octets, MAX-SF-LEN, has arrived at the multiplexer, or
- (2) a timer, called T, has expired.
when either condition is met, the multiplexed PPP payload gets transmitted 🎀
MAX-SF-LEN exists so a PPPMUX payload never goes over the MTU size of any physical link the tunnel might 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 the tunnel may be associated with 🧚
timer T gives tunnel interfaces an upper delay bound ⏰ timer T gets reset whenever a multiplexed payload is sent to the next encapsulation layer 🦋 this behaviour is similar to AAL2's Timer_CU described in [I.363.2] 💜 and each PPPMUX transmitter should have its own Timer T 👑
the best values for T depend on how fast payloads are expected to arrive at the multiplexer and on 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 from multiplexing inside an L2TP tunnel, multiple RTP streams should be active between the source and destination of that 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 apps where lots of RTP sessions run between one pair of RTP endpoints 💅 the number of simultaneous RTP sessions needed to bring header overhead down to the desired level depends on the size of the L2TP header 🎀 a smaller L2TP header means fewer simultaneous RTP sessions are needed to get 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 lets [IPCP-HC] negotiate ECRTP compression/decompression parameters 👑
2.4.1. Tunneling and DiffServ 🌸
RTP streams may be marked with Expedited Forwarding (EF) bits, as described in [EF-PHB] 💜 when a packet like that gets tunneled, the tunnel header must also be marked with 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, looks like this 🌈
+---------+---------+-------------+-----------------------+
| | 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's 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 🌸
3. Bandwidth Efficiency 📈
the bandwidth efficiency you can get with TCRTP depends on a bunch of factors 🧮 these include multiplexing gain, the expected packet loss rate across the network, and how often specific fields in the IP and RTP headers change 🦋 this section also covers how TCRTP seriously boosts bandwidth efficiency for voice over IP over ATM 🔥
3.1. Multiplexing Gains 💖
multiplexing cuts down the overhead tied to the layer 2 and tunnel headers 🫶 the more CRTP payloads you combine into one multiplexed PPP payload, the higher your multiplexing gain 👑 so as traffic goes up within a tunnel, more payloads get packed into one multiplexed payload, and that boosts the gain 🌈
3.2. Packet Loss Rate 💀
losing a multiplexed packet means losing packets for every flow inside it 😭
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 make sure state changes get delivered 🧚 this robust operation is characterized by a parameter N, which means the probability of more than N adjacent packets getting lost on the tunnel is small 🎀
N=1 protects against the loss of a single packet within a compressed session, but it costs bandwidth 💸 N=2 protects 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 best value of N depends 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 🧮
Okay so here's the formula that uses everything we've talked about to model the bandwidth of a single flow, for both voice and video 💖 These are the variables you need to know:
SOV-TCRTP, unit: octet. This is the per-payload overhead of ECRTP plus the multiplexed PPP header. It does not include the extra cost of updating the IP ID or RTP Time Stamp fields (check [ECRTP] for the IP ID details). It assumes the COMPRESSED_RTP payload type 🎀 and adds up to 6 octets: 1 for the ECRTP context ID, 1 for the COMPRESSED_RTP flags, 2 for the UDP checksum, 1 for the PPP protocol ID, and 1 for the multiplexed PPP length field.
POV-TCRTP, unit: octet. This is the per-packet overhead of tunneled ECRTP, covering the tunnel header and the multiplexed PPP payload type. It's 20 octets for the IP header, 4 for the L2TPv3 header, and 1 for the multiplexed PPP protocol ID, for a total of 25 octets 🦋
TRANSMIT-LENGTH, unit: milliseconds. This is the average length of a transmission, like a talk spurt in a voice stream 🎙️
SOV-TSTAMP, unit: octet. This is the extra per-payload overhead of the COMPRESSED_UDP header when it carries the absolute time stamp field. That's 1 octet for the extra flags field plus 4 octets for the absolute time stamp, so 5 octets total ✨
SOV-IPID, unit: octet. This is the extra per-payload overhead of the COMPRESSED_UDP header when it carries the absolute IPID field. That's 2 octets for the absolute IPID and 1 octet for the extra flags field in the COMPRESSED_UDP header, for a total of 3 octets 🌸
IPID-RATIO, unit: integer values 0 or 1. This tells you how often the compressor has to update IPID. If IPID is changing randomly and always needs an update, the value is 1. If IPID changes by a fixed constant amount between payloads of a flow, IPID-RATIO is 0. This variable doesn't count the IPID value at the start of a voice or video transmission, because TRANSMIT-LENGTH already covers that. The sending IP stack and the RTP application control this behaviour. See Section 1.1 🧚
NREP, unit: integer (usually a number between 1 and 3). This is how many times an update field gets repeated in ECRTP headers so the compressor and decompressor are more likely to get it through. For this example, we'll assume NREP=2 💅
PAYLOAD-SIZE, unit: octets. This is the size of the RTP payload in octets 🍓
MUX-SIZE, unit: count. This is how many PPP payloads get squished into one multiplexed PPP payload 🧃
SAMPLE-PERIOD, unit: milliseconds. This is the average gap between transmissions of voice or video payloads for each flow in the multiplex. For example, for voice it's 10ms if every call has a 10ms sample period 🫶
Here's the formula:
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)And these are the results:
BANDWIDTH, unit: kilobits per second. This is the average bandwidth used per voice or video flow 👑
SOV-TOTAL is the total per-payload overhead of tunneled ECRTP. It includes the per-payload overhead of ECRTP and PPP, plus the timestamp update overhead and the IPID update overhead 🔥
3.3.1. Voice Bandwidth Calculation Example 🎧
Let's do a voice example! 💜 The scenario is compressed voice streams using G.729 compression with a 20 millisecond packetization period. VAD is turned on, and the average talk spurt is 1500 milliseconds. The IPID field is changing randomly between payloads of streams, and there's enough traffic in the tunnel to fit 3 multiplexed payloads. The values are:
SAMPLE-PERIOD = 20 milliseconds
TRANSMIT-LENGTH = 1500 milliseconds
IPID-RATIO = 1
PAYLOAD-SIZE = 20 octets
MUX-SIZE = 3So per call bandwidth comes out to 16.4 kbits/sec 🌈 Classical CRTP over a single HDLC link, using the same factors, gives you 12.4 kbits/sec.
IPID can make a big difference to per call bandwidth 👀 If we redo the example with an IPID-RATIO of 0, per call bandwidth drops to 13.8 kbits/sec. Classical CRTP over a single HDLC link, with these same factors, gives you 11.2 kbits/call.
3.3.2. Voice Bandwidth Comparison Table 📊
These bandwidth values are for 5 simultaneous calls, no voice activity detection (VAD), G.729 with a 20ms packetization interval, and without counting 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 🎬
TCRTP can save bandwidth on any RTP-encapsulated flow, so it works for video too 🌟 This section walks through an example with MPEG-2 encoded video. RTP encapsulation of MPEG System and Transport Streams is done as described in RFC 2250. Frames for MPEG-2 video are sent continuously, so TRANSMIT-LENGTH is basically infinite here. The IPID field is changing randomly between payloads of streams, and there's enough traffic in the tunnel for 3 multiplexed payloads. The values are:
SAMPLE-PERIOD = 2.8 milliseconds
TRANSMIT-LENGTH = infinite
IPID-RATIO = 1
PAYLOAD-SIZE = 1316 octets
MUX-SIZE = 3Per flow bandwidth comes out to 3.8 Mbits/sec. MPEG video with no header compression, using the same factors, gives you 3.9 Mbits/sec. TCRTP does save some bandwidth for video, but the headers are such a tiny slice of each payload that the savings are basically insignificant 🙈
3.3.4. TCRTP over ATM ✈️
IP over AAL5 has a quantizing effect on bandwidth use, because packets always come in whole multiples of ATM cells 😭
Take G.729 with 10 millisecond packetization intervals: the payload is 10 octets, which is way smaller than an ATM cell's payload of 48 octets. Classical CRTP [CRTP] used link-by-link has a really good IP overhead to payload ratio. But AAL5 encapsulation and its cell padding always force the minimum payload up to one ATM cell, so bandwidth use ends up poor.
Rather than wasting that padding, TCRTP's multiplexing lets the leftover room in the ATM cell hold useful data instead. This is one of the main reasons multiplexing has such a huge effect on bandwidth use for Voice over IP over ATM 💅
TCRTP's multiplexing efficiency is similar to the AAL2 sub-cell multiplexing described in [I.363.2]. The difference is that TCRTP's efficiency isn't limited to ATM networks 🌸
3.3.5. TCRTP over Non-ATM Networks 🌐
When TCRTP runs over other layer 2 encapsulations that don't have a minimum PDU size, the benefit of multiplexing isn't as big 🥲
How it stacks up against link-by-link CRTP depends on the exact overhead of the layer 2 encapsulation. The per-payload overhead of CRTP tunneling is either 4 or 6 octets. If classical CRTP plus layer 2 overhead is bigger than that, TCRTP multiplexing uses less bandwidth than classical CRTP once the outer IP header gets spread across a lot of payloads ✨
You can work out the payload breakeven point with this formula:
POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX + SOV-PPPMUX
* MUX-SIZEWhere:
POV-L2, unit: octet. This is the layer 2 packet overhead, which is 5 octets for HDLC encapsulation.
POV-TUNNEL, unit: octet. This is the packet overhead from tunneling, which is 24 octets for the IP header and L2TPv3 header.
POV-PPPMUX, unit: octet. This is the packet overhead for the multiplexed PPP protocol ID, which is 1 octet.
SOV-PPPMUX, unit: octet. This is the per-payload overhead of PPPMUX, made up of the payload length field and the ECRTP protocol ID. It's typically 1, 2, or 3 octets.
If you're using HDLC as the layer 2 protocol, the breakeven point from the formula above is when MUX-SIZE = 7. So you need 7 voice or video flows multiplexed before TCRTP is as bandwidth-efficient as link-by-link CRTP compression 🦋
4. Example Implementation of TCRTP ✨
Okay bestie, this section is a walkthrough of one example way to build TCRTP 💖. There are lots of ways to do it, as long as the requirements of the related RFCs are met 🦋.
Here's the journey an RTP packet takes in this setup 🧚:
+-------------------------------+ ^
| 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
+-------------------------------+ VSo a protocol stack gets set up 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 set up to route RTP packets over to this tunnel 🚇. The destination UDP port number could help tell RTP packets apart from non-RTP packets, which is kinda clever ✨.
The transmitting app gathers the RTP data from one source and formats an RTP packet 🎀. Then the lower layers add the UDP and IP headers to make a complete IP packet 📦.
Next, the RTP packets get routed to the tunnel interface, where the headers get compressed, the payloads get multiplexed, and then the packets are tunneled off to the destination host 🫶.
The receiving node does the exact same thing as the transmitter, just in reverse 🔁. Main character energy, honestly 👑.
4.1. Suggested PPP and L2TP Negotiation for TCRTP
This part explains the PPP and L2TP negotiations you need to set up a PPP connection and an L2TP tunnel with L2TP header compression 💅. It's all between two peers, called 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-Ack4.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 ->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
<- ZLB4.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
<- ZLB4.3.3. Tunnel Tear Down
Peer1 Peer2
----- -----
StopCCN ->
Mandatory AVP's:
Message Type
Assigned Tunnel ID
Result Code
<- ZLB5. Security Considerations
Okay, this section is SERIOUS 💀, so read it carefully 🙈. This document describes a method for combining several existing protocols that handle compression, multiplexing, and tunneling of RTP streams 🔐. The attacks on the component technologies of TCRTP include attacks on RTP/RTCP headers and payloads carried inside a TCRTP session, attacks on the compressed headers, attacks on the multiplexing layer, or attacks on the tunneling negotiation or transport 😱. The security issues for each of those component technologies are dealt with in their own specs, [ECRTP], [PPP-MUX], and [L2TPv3], plus the security considerations for RTP itself, [RTP] 📚.
Here's the tea though 🍵. There may be extra security considerations that come up from using these component technologies together. For example, there may be a higher risk of packets from one stream in the multiplex getting accidentally misdelivered to another stream, because of a protocol malfunction or a data error, since the addressing information is more condensed 😬. This is especially true if the tunnel runs over a link-layer protocol that lets through packets containing bit errors, combined with a tunnel transport layer option that doesn't checksum the whole payload 🫠.
The chance of malicious misdirection may also go up, compared to a single RTP stream carried by itself, because the addressing information has to be unencrypted for the header compression and multiplexing layers to work 🚨.
The main defense against misdelivery is to make the data useless to unintended recipients with cryptographic techniques 🔒. The basic encryption method in the RTP specification, [RTP], isn't suitable here, because it encrypts the RTP and RTCP headers along with the payload 🙅. The RTP specification does allow other approaches to be defined in separate profile or payload format specifications, where only the payload portion of the packet gets encrypted. That way, header compression can still be applied to the encrypted packets ✨. One such profile, [SRTP], gives more sophisticated and complete methods for encryption and message authentication than the basic approach in [RTP] 🛡️. More methods may be developed in the future 🔮. Appropriate cryptographic protection should be built into all TCRTP applications 💜.
6. Acknowledgements
The authors want 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.
[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.
Authors' Addresses ✨
Here are the three cuties who wrote this one, all based at the same Cisco office in San Jose 🌴 Bruce, Tmima, and Dan, with their contact details right below 💌
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.comFull Copyright Statement 🎀
Okay, the legal bit, but make it cute 🥹 The Internet Society owns the copyright here, dated 2005. This document is covered by the rights, licenses, and restrictions in BCP 78, and the authors keep all their rights, except for whatever BCP 78 says otherwise.
The document and the information in it are handed over "AS IS", and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim the following, verbatim:
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.So yeah, no guarantees 🙃
Intellectual Property 🔐
The IETF is not picking a side on whether any IPR or other rights that someone might claim over the tech in this doc are valid, or how far any license under those rights would reach, or whether one would even be available. It also isn't claiming it searched for any of that. If you want the rules on rights in RFC documents, go read BCP 78 and BCP 79 🧐
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use the proprietary rights from implementers or users of this spec can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 📂
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📨
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, for keeping the lights on 💖🌈
📦 where this page comes from
- ietf: rfc4170 2005-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms