Audio/Video Transport Working Group Bruce Thompson
Internet Draft Tmima Koren
File: <draft-ietf-avt-tcrtp-05.txt> Dan Wing
Category: Informational Cisco Systems
Expires: June 2002 November 21, 2001
Tunneling Multiplexed Compressed RTP ("TCRTP")
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes a method to improve the end-to-end bandwidth
utilization of RTP streams over an IP network using compression and
multiplexing. This is accomplished by combining three standard
protocols: Enhanced CRTP [ECRTP] for header compression, PPP [PPP]
Multiplexing [PPP-MUX] for multiplexing, and L2TP tunneling [L2TP]
for transmission of PPP over an IP network.
Thompson, Koren, Wing Informational [Page 1]
TCRTP October 2001
Table of Contents
1. Introduction.......................................................3
1.1. Is Bandwidth Costly?.............................................3
1.2. Overview of Protocols............................................3
1.3. Document Focus...................................................3
1.4. Enhanced CRTP....................................................4
1.5. Reducing TCRTP Overhead..........................................4
2. Protocol Operation and Recommended Extensions......................4
2.1. Models...........................................................4
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 Multiplexing with Tunneling...............................6
2.3.2. Tunneling Inefficiencies......................................7
2.4. Tunneling: L2TP..................................................8
2.4.1. Compressing L2TP headers......................................8
2.4.2. Tunneling and DiffServ........................................8
2.5. Encapsulation Formats............................................8
3. Bandwidth Efficiency...............................................9
3.1. Multiplexing gains..............................................10
3.2. Packet loss rate................................................10
3.3. Bandwidth Calculation for Voice Applications....................10
3.3.1. Bandwidth Calculation Example................................12
3.3.2. Bandwidth Comparison Table...................................12
3.3.3. Voice over IP over ATM.......................................13
3.3.4. Voice over IP over non-ATM networks..........................13
4. Example implementation of TCRTP...................................14
4.1. Suggested PPP and L2TP negotiation for TCRTP....................15
4.2. PPP negotiation TCRTP...........................................16
4.2.1. LCP negotiation..............................................16
4.2.2. IPCP negotiation.............................................16
4.3. L2TP negotiation................................................17
4.3.1. Tunnel Establishment.........................................17
4.3.2. Session Establishment........................................17
4.3.3. Tunnel Tear Down.............................................18
5. Security Considerations...........................................18
6. Acknowledgements..................................................18
7. References........................................................18
8. Authors' Addresses................................................19
9. Full Copyright Statement..........................................20
Thompson, Koren, Wing Informational [Page 2]
TCRTP October 2001
1. Introduction
This document describes a way to combine existing protocols for
compression, multiplexing, and tunneling to save bandwidth for RTP
applications.
1.1. Is Bandwidth Costly?
On certain links, such as customer access links, the cost of
bandwidth is widely acknowledged. Protocols such as CRTP [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 discrepency, especially for large
voice trunking applications.
1.2. Overview of Protocols
Header compression is accomplished using Enhanced CRTP [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 eliminates the
IP, UDP, and RTP headers.
Multiplexing is accomplished using PPP Multiplexing [PPP-MUX].
Tunneling PPP is accomplished by using L2TP [L2TP].
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.
1.3. Document Focus
Thompson, Koren, Wing Informational [Page 3]
TCRTP October 2001
This document is primarily concerned with bandwidth savings for Voice
over IP (VoIP) applications. However, the combinations of protocols
described in this document can be used to provide similar bandwidth
savings for other RTP applications such as video.
1.4. 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 this context
and processing time is difficult, 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.
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
point-to-point links.
See section 2.2 for details.
1.5. Reducing TCRTP Overhead
If only one stream is tunneled (L2TP) and compressed (ECRTP) there is
little bandwidth savings. Multiplexing is helpful to amortize the
overhead of the tunnel header over many RTP payloads. The
multiplexing format that is proposed by this document is PPP
multiplexing [PPP-MUX]. See section 2.3 for details.
[L2TP-HC] should be used to reduce the size of L2TP headers. See
section 2.4 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.
2.1. Models
TCRTP can typically be implemented in two ways. The most
straightforward is to implement TCRTP in the gateway terminating the
RTP streams:
[voice gateway]---[voice gateway]
^
Thompson, Koren, Wing Informational [Page 4]
TCRTP October 2001
|
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 gateway]\ /[voice gateway]
[voice gateway]---[concentrator]---[concentrator]---[voice gateway]
[voice gateway]/ \[voice gateway]
^ ^ ^
| | |
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 gateway]\ /[voice gateway]
[voice gateway]---[concentrator]---[concentrator]---[voice gateway]
[voice gateway]/ \[voice gateway]
^ ^ ^
| | |
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 links such as the tunneling proposed by this document.
Thus, ECRTP should be used.
2.2.1. Synchronizing ECRTP States
When the compressor receives an RTP packet which has an unpredicted
change in the RTP header, the compressor should send an
COMPRESSED_UDP packet (described in [ECRTP]) to synchronize the ECRTP
decompressor state. The COMPRESSED_UDP packet updates the RTP
context in the decompressor.
To ensure delivery of updates of context variables, COMPRESSED_UDP
packets should be delivered using the robust operation described in
[ECRTP].
Thompson, Koren, Wing Informational [Page 5]
TCRTP October 2001
As 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 in order delivery of packets.
Therefore, the ECRTP decompressor must operate correctly in the
presence of out of order packets.
2.3. Multiplexing: PPP Multiplexing
Both CRTP and ECRTP requires a layer two protocol which allows
identifying different protocols. [PPP] is suited for this.
Unlike a point-to-point link, transmissions over a network always
contain some routing information. It is beneficial to transmit large
multiplexed packets between two points instead of many small packets,
as it reduces the load of the network (fewer packets to route) and
provides better efficiency (better ratio of payload versus routing
information). Depending on the implementation of TCRTP, these
efficiencies may be obtained "for free", or may incur additional
delay or jitter.
[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.
During PPP establishment of the TCRTP tunnel, only LCP and IPCP (for
header compression) is required -- IP addresses do not need to be
negotiated, nor is authentication necessary. See section 4.1 for
details.
2.3.1. PPP Multiplexing with Tunneling
In many PPP multiplexing implementations, the PPP multiplex
transmitter will send packets to a tunnel encapsulation module. The
tunnel encapsulation module will typically be implemented above the
IP layer. This means that when the PPP multiplex transmitter
encapsulates packets, the outbound physical interface for the packet
will not be known. The result of this implementation is PPP payloads
will never be multiplexed!
To enable the PPP multiplex transmission algorithm to work properly
with tunneling, some modifications to the transmission logic are
Thompson, Koren, Wing Informational [Page 6]
TCRTP October 2001
needed. For example, the transmission logic of the PPP transmitter
could be modified to collect incoming payloads until one of two
conditions occurred:
(1) a specific number of bytes, called P, has arrived at the
multiplexer, or;
(2) a timer, called T, has expired.
When either condition is satisfied, the multiplexed PPP payload is
transmitted.
The first condition ensures that the multiplexer encapsulates
multiple payloads in the same PPP multiplex payload independent of
the method used to hand packets to the next encapsulation layer.
The second condition provides an upper delay bound. Without this
upper bound, a low arrival rate can cause unacceptable delays. Low
arrival rates could be due to many factors, such as network
congestion, low number of multiplexed flows, or several flows with no
voice activity. 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 tunnel would
have its own Timer T.
The optimal values for P and 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. The value of P
should be chosen to avoid layer 2 fragmentation (which causes
performance loss) and to avoid sending large payloads (which can
cause serialization delays). Optimal values of P will require
knowledge of the network topology, link speed, and MTU between the
TCRTP endpoints.
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.
Thompson, Koren, Wing Informational [Page 7]
TCRTP October 2001
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 a minimum 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.
2.4.1. Compressing L2TP headers
[L2TP-HC] describes a method of compressing L2TP tunnel headers from
36 bytes (including the IP header) to 20 bytes. L2TP Header
Compressed packets include an IP header with the L2TPHC protocol ID,
and omit the UDP and L2TP headers. The result is the overhead of the
L2TP tunnel is only 20 bytes.
L2TP header compression is negotiated during tunnel establishment.
Its use is recommended as it substantially increases the efficiency
of TCRTP.
2.4.2. 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) | |
Thompson, Koren, Wing Informational [Page 8]
TCRTP October 2001
+---------+---------+-------------+-----------------------+
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 bytes| (0-2) | | |1-2 bytes| (0-2) | |
+-------+---------+-------+-----+ +---------+-------+-----+
The format of an L2TP Header Compressed packet with a PPP payload as
defined by [L2TP-HC] is:
+-------------------+---------------------------------|
| IP header | PPP payload |
| (20) | |
+-------------------+---------------------------------+
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 bytes| (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 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
Thompson, Koren, Wing Informational [Page 9]
TCRTP October 2001
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.
The optimal value of N will depend on the loss rate in the tunnel.
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.
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 Applications
The following formula uses the factors described above to model per-
flow bandwidth usage. These variables are defined:
SOV-TCRTP, unit: byte. 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 byte for the
ECRTP context ID, 1 byte for COMPRESSED_RTP flags, 2 bytes for
the UDP checksum, 1 byte for PPP protocol ID, and 1 byte for the
multiplexed PPP length field. The total is 6 bytes.
Thompson, Koren, Wing Informational [Page 10]
TCRTP October 2001
POV-TCRTP, unit: byte. Per-packet overhead of tunneled ECRTP.
This is the overhead for the tunnel header and the multiplexed
PPP payload type. This value is 20 bytes for the IP header, and
1 byte for the multiplexed PPP protocol ID. The total is 21
bytes.
TRANSMIT-LENGTH, unit: milliseconds. The average duration of a
transmission (such as a talk spurt for voice streams).
SOV-TSTAMP, unit: byte. Additional per-payload overhead of the
COMPRESSED_UDP header that includes the absolute time stamp
field. This value includes 1 byte for the extra flags field in
the COMPRESSED_UDP header and 2 bytes for the absolute time
stamp for a total of 3 bytes.
SOV-IPID, unit: byte. Additional per-payload overhead of the
COMPRESSED_UDP header that includes the absolute IPID field.
This value includes 2 bytes for the absolute IPID. This value
also includes 1 byte for the extra flags field in the
COMPRESSED_UDP header. The total is 3 bytes.
IPID-RATIO, unit: integer values 0 or 1. Indicate the frequency
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 talk spurts, 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: bytes. The size of the RTP payload in bytes.
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 a voice payload for all calls in the
multiplex. The value of this variable is 10ms if all calls
have a 10ms sample period.
Thompson, Koren, Wing Informational [Page 11]
TCRTP October 2001
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 call.
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. Bandwidth Calculation Example
To create an example 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 bytes
MUX-SIZE = 3
For this example, per call bandwidth is 14.4 kbits/sec. Classical
CRTP over a single HDLC link using the same factors as above yields
12.4 kbits/sec.
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.2 kbits/sec. Classical CRTP over
a single HDLC link using these same factors yields 11.2 kbits/call.
3.3.2. Bandwidth Comparison Table
Thompson, Koren, Wing Informational [Page 12]
TCRTP October 2001
Using 5 simultaneous calls, no voice activity detection (VAD), G.729
with 20ms packetization interval, not considering RTCP overhead:
Normal VoIP over PPP: 124kbps
with classical CRTP on a link: 50kbps (savings: 59%)
with TCRTP over PPP: 56kbps (savings: 55%)
with TCRTP over AAL5: 85kbps (savings: 31%)
3.3.3. Voice over IP over ATM
IP transport over AAL5 causes a quantizing effect to bandwidth
utilization due to the packets always being multiples of ATM cells.
For example, the payload size for G.729 using 10 millisecond
packetization interval is 10 bytes. This is much smaller than the
payload size of an ATM cell (48 bytes). 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.1]. Unlike AAL2 sub-cell
multiplexing, however, TCRTP's multiplexing efficiency isn't limited
to only ATM networks.
3.3.4. Voice over IP over non-ATM networks
When TCRTP is used with other layer 2 encapsulations that do not have
a minimum PDU size, the benefits of multiplexing is not as great.
Depending upon the exact overhead of the layer 2 encapsulation, the
benefits of VOIP 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 bytes. 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.
Thompson, Koren, Wing Informational [Page 13]
TCRTP October 2001
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: byte. Layer 2 packet overhead: 5 bytes for HDLC
encapsulation
POV-TUNNEL, unit: byte. Packet overhead due to tunneling: 20
bytes IP header
POV-PPPMUX, unit: byte. Packet overhead for the multiplexed PPP
protocol ID: 1 byte
SOV-PPPMUX, unit: byte. 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 = 6. Thus 6 voice calls need to be
multiplexed to make TCRTP bandwidth-efficient.
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:
+-------------------------------+ ^
| Application | |
+-------------------------------+ |
| RTP | |
+-------------------------------+ Application and
| UDP | IP stack
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| IP forwarding
|
Thompson, Koren, Wing Informational [Page 14]
TCRTP October 2001
+-------------------------------+ ^
| 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 multiplexed, and then tunneled to the
destination host.
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.
Thompson, Koren, Wing Informational [Page 15]
TCRTP October 2001
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
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
Thompson, Koren, Wing Informational [Page 16]
TCRTP October 2001
and sub-parameters
as described in
[IPCP-HC] and [ECRTP]
Configure-Ack ->
4.3. L2TP negotiation
L2TP is described in [L2TP], and L2TP header compression is described
in [L2TP-HC].
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
L2TP-HC AVP [L2TP-HC]
<- ICRP
Mandatory AVP's:
Thompson, Koren, Wing Informational [Page 17]
TCRTP October 2001
Message Type
Assigned Session ID
L2TP-HC AVP
ICCN ->
Mandatory AVP's:
Message Type
Tx (Connect Speed)
Framing Type
<- ZLB
4.3.3. Tunnel Tear Down
Peer1 Peer2
----- -----
StopCCN ->
Mandatory AVP's:
Message Type
Assigned Tunnel ID
Result Code
<- ZLB
5. Security Considerations
This draft does not impose additional security considerations beyond
those that apply to L2TP, PPP and ECRTP.
6. Acknowledgements
The authors would like to thank the authors of RFC2508, Stephen
Casner and Van Jacobson, and the authors of RFC2507, 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
[L2TP-HC] A. Valencia, "L2TP Header Compression ("L2TPHC") ",
draft-ietf-l2tpext-l2tphc-04.txt, October 2001.
Thompson, Koren, Wing Informational [Page 18]
TCRTP October 2001
[PPP-MUX] R. Pazhyannur, I. Ali, C. Fox, "PPP Multiplexing", RFC3153,
August 2001.
[ECRTP] T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy,
"Compressing IP/UDP/RTP headers on links with high delay, packet
loss, and reordering", draft-ietf-avt-crtp-enhance-03.txt,
November 2001.
[CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC2508, February 1999.
[IPHCOMP] M. Degermark, B. Nordgren, S. Pink, "IP Header
Compression", RFC2507, February 1999.
[IPCP-HC] M. Engan, S. Casner, C. Bormann, "IP Header Compression
over PPP", RFC2509, February 1999.
[RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A
Transport Protocol for Real-Time Applications", RFC1889, January
1996.
[L2TP] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B.
Palter, "Layer Two Tunneling Protocol "L2TP"", RFC2661, August
1999.
[I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2
AAL", I.363.2, September 1997.
[EF-PHB] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding
PHB", RFC2598, June 1999.
[PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC1661, July
1994.
8. 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
Thompson, Koren, Wing Informational [Page 19]
TCRTP October 2001
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
Phone: +1 408 525 5314
Email: dwing@cisco.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
ôAS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Thompson, Koren, Wing Informational [Page 20]
TCRTP October 2001
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Thompson, Koren, Wing Informational [Page 21]