[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-wing-avt-tcrtp) 00 01 02 03 04 05 06 07 08 RFC 4170

Audio/Video Transport Working Group                      Bruce Thompson
Internet Draft                                              Tmima Koren
File: <draft-ietf-avt-tcrtp-07.txt>                            Dan Wing
                                                          Cisco Systems
Expires: June 2003                                     November 2, 2002


            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.


Note to RFC Editor:

Please replace [RFCXXXX] by the RFC number that will be allocated to
draft-ietf-avt-crtp-enhance-04.txt


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 to reduce
the bandwidth used when multiple RTP streams are carried over that
path.

This method was selected by the IETF Audio/Video Transport working
group as best satisfying the need for standardized RTP multiplexing
because it preserves full RTP semantics.  Other methods may be more
highly optimized for particular applications by constraining their
applicability, for example to a small set of encodings and a subset of
the RTP semantics.  Those other methods may be more appropriate as
proprietary protocols rather than standards.


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. 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 Multiplex Transmitter Modifications for Tunneling.........6
2.3.2.  Tunneling Inefficiencies......................................8
2.4. Tunneling: L2TP..................................................8
2.4.1.  Compressing L2TP headers......................................8
2.4.2.  Tunneling and DiffServ........................................8
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 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....................16
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. IANA Considerations...............................................18
6. Security Considerations...........................................18
7. Acknowledgements..................................................19
8. References........................................................19
9. Authors' Addresses................................................20
10. Full Copyright Statement.........................................21


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 [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)
described in [RFCXXXX]. 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 [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

  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 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.

  A simplistic solution is to use CRTP with L2TP to achieve end-to-end
  CRTP.  However, as described in [RFCXXXX], CRTP is only suitable for
  links with low delay and low loss.

ROHC [ROHC] defines another header compression algorithm for
point-to-point links that is very efficient and robust against packet
loss.  While there is nothing in either PPP multiplexing or L2TP that
precludes the use of ROHC as the compression mechanism, ROHC does not
tolerate the misordering of compressed packets between the compressor
and decompressor that may occur when these packets are carried across
an IP tunnel.  Since the multiplexing method described in this
document uses IP tunnels, both packet loss and misordering may occur.
Therefore, the Enhanced CRTP algorithm specified in [RFCXXXX], which
includes optimizations to CRTP to deal with both packet loss and
misordering between the compressor and decompressor, is used instead.

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 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 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 [RFCXXXX], 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 a
  COMPRESSED_UDP packet (described in [RFCXXXX]) 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
  [RFCXXXX].

As the "twice" algorithm described in [RFCXXXX] 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 [RFCXXXX].

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 require a layer two protocol which 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.

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 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.

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.

2.4.1. Compressing L2TP headers

  [L2TP-HC] describes a method of compressing L2TP tunnel headers from
  36 octets (including the IP header) to 20 octets. 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 octets.

  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)   |                       |
     +---------+---------+-------------+-----------------------+


  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 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 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 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 Applications

  The following formula uses the factors described above to model per-
  flow bandwidth usage.  These variables are defined:

     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
       [RFCXXXX] 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,
       and 1 octet for the multiplexed PPP protocol ID. The total is 21
       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 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: octets. The size of the RTP payload in octets.

     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.

  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 octets
     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

  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 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.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 benefit of multiplexing is not as great.

  Depending upon the exact overhead of the layer 2 encapsulation, the
  benefit 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 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

     POV-TUNNEL, unit: octet.  Packet overhead due to tunneling: 20
       octets IP 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 = 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
                      |
      +-------------------------------+             ^
      |             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.
  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
  [RFCXXXX].

           Peer1                       Peer2
           -----                       -----
  Configure-Request              ->
    Options:
    IP-Compression-Protocol
      Use protocol 0x61
      and sub-parameters
      as described in
      [IPCP-HC] and [RFCXXXX]
                                  <- Configure-Ack
                                  <- Configure-Request
                                       Options:
                                       IP-Compression-Protocol
                                         Use protocol 0x61
                                         and sub-parameters
                                         as described in
                                         [IPCP-HC] and [RFCXXXX]
  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:

                                       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. IANA Considerations

  This document does not require any assignments from IANA.


6. Security Considerations

This document describes a method for combining several existing
protocols implementing 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, [RFCXXXX], [PPP-MUX], [L2TP], and [L2TP-HC], 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 so header compression may be applied to the encrypted
packets.  One such profile is currently being developed [SRTP] to
provide more 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.


7. 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.


8. References

  Normative References

  [L2TP-HC] A. Valencia, "L2TP Header Compression ("L2TPHC") ",
       draft-ietf-l2tpext-l2tphc-06.txt, November 2002.

  [PPP-MUX] R. Pazhyannur, I. Ali, C. Fox, "PPP Multiplexing", RFC3153,
       August 2001.

  [RFCXXXX] 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-05.txt,
       November 2002.

  [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.

  Informative References

[RFCYYYY] T. Baugher, D. McGrew, D. Oran, et-al, "The Secure Real-time
      Transport Protocol", draft-ietf-avt-srtp-05.txt, June 2002.

[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
      H., Hannu, H., Jonsson, L., 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.


9. 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

   Phone: +1 408 525 5314
   Email: dwing@cisco.com


10. 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
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/