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]