[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 March 3, 2000                                 Tmima Koren
Expires October 2000                                            Dan Wing
draft-ietf-avt-tcrtp-00.txt                                Cisco Systems




             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 (2000).  All Rights Reserved.


1. 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. Several
application level compression/multiplexing solutions have been evaluated so far
in the IETF AVT Working Group. This proposal differs from other solutions in
that neither compression nor multiplexing needs to be done at application level.
Because of this, existing RTP based applications do not need to change to
support this encapsulation format.

Instead of proposing a new encapsulation format for end to end multiplexing,
this document describes the application of existing protocols for compression,
multiplexing, and end to end tunneling.

2. Introduction

This document describes the application of existing protocols for compression,
multiplexing, and end to end tunneling that can be used by RTP applications to
implement an end to end multiplexing scheme for RTP transport. Header
Compression is used to reduce the header overhead of a single RTP payload.
Tunneling is used to transport compressed headers and payloads through a
multiple hop IP network without having to compress and decompress at each link.
Multiplexing is used to reduce the overhead of tunnel headers by amortizing a
single tunnel header over many RTP payloads.

For compression, this document proposes the use of RFC 2508 based RTP header
compression (CRTP). RFC 2508 describes the use of RTP header compression on an
unspecified link layer transport. Most CRTP implementations use PPP as the link
layer transport for the session. PPP has been integrated with a number of
physical link layer protocols such as HDLC. When PPP is integrated with a
physical link layer for CRTP transport, it has the disadvantage that headers
must be compressed and decompressed at each IP hop in an end to end network.

A CRTP session can be made to work across multiple IP hops to enable end to end
compression by tunneling the PPP session. The tunneling protocol proposed by
this document is L2TP (RFC 2661). L2TP is a general tunneling protocol for PPP
sessions. Since PPP is used as the link layer protocol for CRTP, the extensions
described in RFC 2509 are required to negotiate the CRTP session.

When the overhead of a tunnel header is added to a single compressed RTP
payload, there is very little bandwidth savings when compared to uncompressed
transport of RTP streams. Multiplexing is required to amortize the overhead of
the tunnel header over many RTP payloads. The multiplexing format that is
proposed by this document is PPP multiplexing (Draft-ietf-pppext-pppmux-00.txt).
PPP multiplexing allows many PPP payloads to be encapsulated as a single
multiplexed PPP payload. The resulting multiplexed PPP payload can then be
transported between two RTP endpoints using L2TP.

In order to make end to end transport of CRTP sessions efficient when using
L2TP, some extensions are needed to both the CRTP protocol and the L2TP
protocol. This document describes extensions that have been proposed for these
protocols to make them more efficient when they are used as described in this
document. These extensions to CRTP and L2TP have been proposed in separate
Internet drafts.


3. Protocol Operation and Recommended Extensions

3.1. CRTP

When CRTP sessions are transported through a network using an L2TP tunnel, some
of the basic assumptions used for CRTP over a single physical link may no longer
be valid. Tunneling a CRTP session through multiple IP hops may increase the
round trip delay and the chance of packet loss. CRTP contexts get invalidated
due to packet loss. The CRTP error recovery mechanism using CONTEXT_STATE
messages can compound the loss problem when long round trip delays are involved.
This is because once the CRTP decompressor context state gets out of sync with
the compressor, it will drop packets associated with the context until the two
states are resynchronized. Resynchronization involves the transmission of the
CONTEXT_STATE message from the decompressor to the compressor, and a FULL_HEADER
message from the compressor to the decompressor.

Enhancements to CRTP are needed to minimize feedback based error recovery using
context state messages. Draft-koren-avt-crtp-enhance-01.txt proposes CRTP
enhancements to make it more tolerant of packet loss, and minimize the need to
use the CRTP error recovery mechanism. Specific recommendations for the use of
the CRTP protocol when transported through a tunnel are described below.

The CU* packet format described in Draft-koren-avt-crtp-enhance-01.txt should be
used to synchronize CRTP compressor and decompressor state whenever the incoming
packet stream causes a change in the compressor context state. The CU* packet
format allows any portion of the context state to be transmitted from the
compressor to the decompressor.

To ensure delivery of state changes, CU* packets should be delivered using
either the N mode of operation or the ACK mode of operation described in Draft-
koren-avt-crtp-enhance-01.txt. The method that should be used depends on the
expected loss rate of packets in the network. Networks with a low loss rate for
packets in the tunnel should use the N mode of operation. Networks with a high
loss rate should use the ACK mode of operation.

UDP checksums should be used for RTP packets transported using TCRTP. The twice
algorithm described in RFC 2508 should be used by the CRTP decompressor to
resynchronize context state in the event of packet loss within the tunnel. In
the event that UDP checksums are not generated by the application, the CRTP
compressor should use the CRTP Headers checksum described in Draft-koren-avt-
crtp-enhance-01.txt.

Tunneled transport does not guarantee in order delivery of packets. Therefore,
the CRTP decompressor must be capable of operation in the presence of out of
order packet delivery. A CRTP decompressor may treat out of order delivery the
same as packet loss. There is no need to reorder packets that are delivered out
of order.


3.2 PPP Multiplexing

Draft-ietf-pppext-pppmux-00.txt describes an encapsulation that allows combining
multiple PPP payloads into one multiplexed payload. The encapsulation format
used for PPP multiplexing allows any supported PPP payload type to be
multiplexed.


3.3. L2TP

L2TP tunnels should be used to tunnel the CRTP payloads end to end. This is a
natural choice since CRTP payloads are PPP payloads, and L2TP allows tunneled
transport of PPP payloads. L2TP includes methods for tunneling messages used in
PPP session establishment such as NCP. This allows the procedures of RFC 2509 to
be used for negotiating the use of CRTP within a tunnel and to negotiate
compression/decompression parameters to be used for the CRTP session.

To get reasonable bandwidth efficiency using multiplexing within an L2TP tunnel,
multiple RTP streams must 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 CRTP 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 a minimum depends on how big
the L2TP header is. A smaller L2TP header will result in fewer simultaneous RTP
sessions being required to produce bandwidth efficiencies similar to CRTP.

Draft-ietf-l2tpext-l2tphc-00.txt describes a method of compressing L2TP tunnel
headers from 36 bytes including the IP header to 21 bytes. L2TPHC packets
include an IP header, using an IP protocol that is negotiated between the two
hosts at the ends of the L2TP tunnel. The UDP header is omitted, and the L2TPHC
header is reduced to 1 byte. The added overhead is now 21 bytes of the combined
IP and L2TPHC headers.

When L2TP is used to carry CRTP streams, the RTP streams may use the EF DSCP.
When an EF packet is tunneled, the tunnel header must be marked as EF. This is a
requirement of RFC 2598. To prevent TCRTP tunnels from using excess EF
bandwidth, it is recommended that only packets marked with the EF DSCP be
transported in the tunnel.

3.4 Encapsulation Formats

The packet format for an RTP packet compressed with RTP header compression
As defined in RFC 2508 is:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         +   MSTI  +             +                       |
   | Context +         +     UDP     +                       |
   |   ID    +   Link  +   Checksum  +       RTP Data        |
   |         + Sequence+             +                       |
   |  (1-2)  +   (1)   +     (0,2)   +                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The packet format of a multiplexed PPP packet is as follows:
(diagram taken from draft-ietf-pppext-pppmux-00.txt)

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+
   | Mux   +P|       +       +     +   +P|       +       +     +
   | PPP   +F| Len1  +  PPP  +     +   +F| LenN  +  PPP  +     +
   | Prot. +F|       + Prot. +Info1+ ~ +F|       + Prot. +InfoN+
   | Field + |(7bits)+ Field1+     +   + |(7bits)+FieldN +     +
   | (2)   +(1 byte )+ (0-2) +     +   +(1 byte) + (0-2) +     +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+


The format of an L2TPHC packet with a PPP payload is:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IP header        | L2TPHC |       PPP payload                |
   |                   | Header |                                  |
   |    (20)           |  (1)   |                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The combined format used for TCRTP with a single payload is:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IP hdr | L2TPHC| Mux   +P|       +       +         + MSTI  +       +      |
   |        | Header| PPP   +F| Len1  +  PPP  + Context +       + UDP   + RTP  |
   | (20)   |  (1)  | Prot. +F|       + Prot. +   ID    + Link  + Cksum + Data |
   |        |       | Field + |(7bits)+ Field1+         + Seq   +       +      |
   |        |       | (2)   +(1 byte )+ (0-2) +  (1-2)  + (1)   + (1-2) +      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

CRTP is defined in RFC2508

Extensions to CRTP to make it more tolerant to packet loss are defined in:
draft-koren-avt-crtp-enhance-01.txt.

L2TPHC is defined in:  draft-ietf-l2tpext-l2tphc-00.txt

PPP multiplexing is defined in:  draft-ietf-pppext-pppmux-00.txt


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
      |              UDP              |             |
      +---+---+---+---+---+---+---+---+             |
      |              IP               |             |
      +---+---+---+---+---+---+---+---+             +
                      |
                      |
                      |  IP forwarding
                      |
                      +
      +---+---+---+---+---+---+---+---+             +
      |             CRTP              |             |
      +---+---+---+---+---+---+---+---+             |
      |            PPPMUX             |             |
      +---+---+---+---+---+---+---+---+          Tunnel
      |             PPP               |         Interface
      +---+---+---+---+---+---+---+---+             |
      |             L2TP              |             |
      +---+---+---+---+---+---+---+---+             |
      |            Layer 2            |             |
      +---+---+---+---+---+---+---+---+             +

A protocol stack is configured to create an L2TP tunnel interface to a
destination host. The tunnel is configured to negotiate NCP IPCP with CRTP
header compression and PPPMUX. IP forwarding is configured to route packets with
the same destination address of the previously configured L2TP tunnel interface
to that tunnel interface. To ensure that other traffic destined to the same IP
address is not routed to this tunnel interface, the forwarding module should be
configured to examine additional information in the IP packet. The destination
UDP port number is an example of the additional information that may be used to
select the L2TP tunnel interface.

The transmitting application gathers the RTP data 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 they are compressed,
multiplexed, and tunneled to the destination host.

The operation of the receiving node is the same as the transmitting node in
reverse.


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

4. References

   [L2TPHC] A. Valencia, "L2TP Header Compression (`L2TPHC')",
   draft-ietf-l2tpext-l2tphc-00.txt, January 2000.

   [PPPMUX] R. Pazhyannur, I. Ali, "PPP Multiplexed Frame Option",
   draft-ietf-pppext-pppmux-00.txt, January 2000.

   [ECRTP] T. Koren, S. Casner, P. Ruddy, B. Thompson, A. Tweeedly, D. Wing,
   J. Geevarghese, "Enhancements to IP/UDP/RTP Header Compression",
   draft-koren-avt-crtp-enhance-01.txt, March 2000.

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

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


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

6.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.109, available from https://tools.ietf.org/tools/rfcmarkup/