[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
July 19, 2001                                            Dan Wing
Expires March 2002                                       Cisco Systems
draft-ietf-avt-tcrtp-04.txt


             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.


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. 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 RTP header
   compression (CRTP) based on RFC 2508 with extensions. Some other
   IP/UDP/RTP header compression protocol could be used so long as it
   performs well over connections with some packet loss, potentially
   long delay, and where packet order may not be maintained.

   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-03.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 specified 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 specified in [ECRTP] and
   [L2TPHC].

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-ietf-avt-crtp-enhance-
   02.txt specifies an enhanced version of CRTP to make it more
   tolerant of packet loss, and to 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 enhanced COMPRESSED_UDP packet format described in Draft-ietf-
   avt-crtp-enhance-02.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
   COMPRESSED_UDP packet format allows any portion of the context state
   to be transmitted from the compressor to the decompressor.

   To ensure delivery of state changes, COMPRESSED_UDP packets should
   be delivered using the N mode of operation described in Draft-ietf-
   avt-crtp-enhance-02.txt

   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-ietf-avt-crtp-enhance-
   02.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-03.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.

   Draft-ietf-pppext-pppmux-03.txt describes the logic of an example
   PPP multiplexing transmitter. When PPP multiplexing is used with an
   L2TP tunnel, the transmitter will typically not have access to an
   interface transmit queue. 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 is that in
   implementations such as this, the PPP multiplex transmission
   algorithm as described in draft-ietf-pppext-pppmux-03.txt will never
   multiplex multiple PPP payloads into one multiplex PPP payload.

   To enable the PPP multiplex transmission algorithm to work properly
   in tunneled implementations, some modifications to the transmission
   logic are needed. The transmission logic could be modified to
   collect incoming payloads to be multiplexed until one of two
   conditions occurred. The first condition is that a target number (N)
   of payloads or bytes has arrived at the multiplexer. The second
   condition is that a timer (T) which bounds delay in the multiplexer
   has expired. The first condition is used to ensure 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 is used to always bound
   the amount of delay to an acceptable value. Delay due to
   multiplexing may become unacceptable in cases where there are not
   enough payloads arriving at the multiplexer to allow the multiplexed
   packet to be sent in a timely manner using only the first condition.
   The timer is reset whenever a multiplexed payload is sent to the
   next encapsulation layer.

   The optimal values for N and T will vary depending upon the rate at
   which payloads are expected to arrive at the multiplexer and the
   amount of acceptable delay allowed in the network.

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-03.txt describes a method of compressing
   L2TP tunnel headers from 36 bytes including the IP header to 20
   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 also
   eliminated. The added overhead is now 20 bytes of the L2TP IP
   header.

   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 with EF
   DSCP.

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-03.txt)

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+
   | 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 L2TPHC packet with a PPP payload is:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IP header        |      PPP payload                |
   |                   |                                 |
   |    (20)           |                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IP header | Mux   |P L|     |       |       | MSTI|       |     |
   |           | PPP   |F X|Len1 |  PPP  |Context|     | UDP   |RTP  |
   |    (20)   | Prot. |F T|     | Prot. |  ID   | Link| Cksum |Data |
   |           | Field |         | Field1|       | Seq |       |     |
   |           | (1)   |1-2 bytes| (0-2) | (1-2) | (1) | (0-2) |     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   CRTP is defined in RFC2508

   Extensions to CRTP to make it more tolerant to packet loss are
   defined in: draft-ietf-avt-crtp-enhance-02.txt.
   L2TPHC is defined in:  draft-ietf-l2tpext-l2tphc-03.txt

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

4. Bandwidth Efficiency

   The expected bandwidth efficiency attainable with TCRTP depends upon
   a number of factors. These factors include multiplexing gain,
   expected loss rate within the tunnel, and rates of change of fields
   within the IP and RTP headers.  This section also describes how
   TCRTP significantly enhances bandwidth efficiency for voice over IP
   over ATM.

4.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 will be able to be combined
   in one multiplexed payload. This will increase multiplexing gain.
   The effect of multiplexing gain on per flow bandwidth will decrease
   as more payloads are added to the multiplexed payload.

4.2 Packet loss rate

   When the expected loss rate in a tunnel is relatively low (<5%), the
   "N mode" should be sufficient to ensure delivery of state changes
   (described in draft-ietf-avt-crtp-enhance-02.txt). The optimal value
   of N will vary depending on the loss rate in the tunnel. A value of
   N=2 will protect against the loss of a single packet within a
   compressed session. A value of N=3 will protect against the loss of
   two packets in a row within a compressed session and so on.

4.3 Changing headers

   There are two fields in the RTP/UDP/IP header whose deltas are
   likely to change fairly often. These fields are the RTP Time Stamp
   and the Identification field in the IP header.

4.3.1  Voice Activity Detection

   For voice applications, voice activity detection will cause an
   unpredictable gap in the RTP Time Stamp field whenever a new talk
   spurt begins. This gap in the RTP Time Stamp field will cause a
   change in the CRTP Time Stamp delta field. To allow all the
   compressed state information for the RTP Time Stamp field to be
   updated in the event of packet loss, the new RTP timestamp needs to
   be delivered at the beginning of a talk spurt. The COMPRESSED_UDP
   compressed header format is used to deliver the absolute RTP
   timestamp. N mode is used to ensure these changes are transmitted
   from compressor to decompressor.

4.3.2  IPID

   Depending on the implementation of the source node of an RTP flow,
   the Identification field in the IP header (IPID) can change randomly
   from packet to packet within a flow.

   An IP transmitter typically increments the IPID field by a constant
   value from packet to packet, but the delta IPID between two packets
   within an RTP flow may actually change by any value. When
   compressing an RTP stream where the IPID is not incrementing by a
   constant value, the best way to maintain context synchronization is
   to use the COMPRESSED_UDP header format and include the absolute
   IPID in each compressed packet.

4.4  Bandwidth calculation formula

   The formula below uses the factors that have been described above to
   come up with a model for per flow bandwidth usage.

   The following variables are defined:

   SOV-TCRTP = The per sample overhead of CRTP and the multiplexed PPP
   header in bytes. This value does not include additional overhead for
   updating IPID or the RTP Time Stamp fields. The value assumes the
   use of the COMPRESSED_RTP payload type. It consists of 1 byte for
   the CRTP 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. This gives a total of 6 bytes.

   POV-TCRTP = The per packet overhead of tunneled CRTP in bytes. 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. Additional overhead needed to
   be added for layer 2 encapsulation. For HDLC, the layer 2 overhead
   would be 5 bytes. This gives a total per packet overhead of 26
   bytes.

   VAD-LENGTH = The average length of a talk spurt for voice streams
   with voice activity detection enabled. This is typically around 1500
   msec. Expressed in milliseconds.

   SOV-TSTAMP = The additional per sample 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 = The additional per sample 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 = The frequency that IPID need to be updated. This value
   is 0 or 1. If IPID is changing randomly and always needs to be
   updated, then IPID-RATIO will be 1. If IPID is changing by a
   constant amount between samples of a flow, then IPID-RATIO will be
   0.

   N = The value of N for N mode. This is the number of times an update
   field will be repeated in CRTP headers to increase the delivery rate
   between the compressor and decompressor. For this example, we will
   assume N=2.

   PAYLOAD-SIZE = The size of the voice payload in bytes.

   MUX-SIZE = The number of PPP payloads to be multiplexed into one
   multiplexed PPP payload.

   SAMPLE-PERIOD = The average sample period of all calls in the
   multiplex. In msec.

   BANDWIDTH = The average amount of bandwidth used per call.
               In kbits / sec.

   SOV-TOTAL = The total amount of per sample overhead associated with
   tunneled CRTP. It includes the per sample overhead of CRTP and PPP,
   timestamp update overhead, and IPID update overhead.

   SOV-TOTAL = SOV-TCRTP +
               SOV-TSTAMP * (N * SAMPLE-PERIOD / VAD-LENGTH) +
               SOV-IPID   * (N * IPID-RATIO)

   BANDWIDTH  = ((PAYLOAD-SIZE + SOV-TOTAL +
                   (POV-TCRTP / MUX-SIZE)) * 8) / SAMPLE-PERIOD)

   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 msec packetization period. In this scenario,
   VAD is enabled and the average talk spurt length is 1500 msec. The
   IPID field is changing randomly between payloads of streams. There
   is enough traffic in the tunnel to allow 3 payloads to be
   multiplexed in a multiplexed PPP payload. The following values
   apply:

   SAMPLE-PERIOD = 20 msec
   VAD-LENGTH    = 1500 msec
   IPID-RATIO    = 1
   PAYLOAD-SIZE  = 20 bytes
   MUX-SIZE      = 3

   For this example, per call bandwidth is 16 kbits/sec. Non tunneled
   CRTP over a single HDLC link using the same factors as above yields
   12.8 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 14.4 kbits/sec. Non tunneled CRTP
   over a single HDLC link using these same factors yields 12
   kbits/call.

4.5 TCRTP Efficiency for Voice over IP over ATM

   Layer 2 encapsulation can have a large effect on the amount of
   bandwidth used with TCRTP encapsulation. Multiplexing gain has a
   dramatic effect on bandwidth when ATM encapsulation is used. IP
   transport over AAL-5 causes a quantizing effect to bandwidth
   utilization. This is because packet sizes will always be in
   multiples of ATM cell sizes, due to the small sample sizes
   associated with voice with low bit rate coders.

   For example, the sample size for a G.729 coder using 10 msec sample
   rate is 10 bytes. This is much smaller than the payload size of an
   ATM cell (48 bytes). When standard IP header compression schemes
   (CRTP) are applied in an ATM environment, the result is VOIP packets
   that are small. However, AAL-5 encapsulation and the resulting cell
   padding cause the minimum PDU size to be one ATM cell.

   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.

4.6. TCRTP Efficiency for 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 sample overhead of
   CRTP tunneling is either 4 or 6 bytes. If classical CRTP plus layer
   2 overhead is greater than this amount, VOIP multiplexing will end
   up having lower bandwidth than classical CRTP when the outer IP
   header is amortized over a large number of samples.

   The breakeven point in samples can be determined by the following
   formula:
   POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX +
                                         SOV-PPPMUX * MUX-SIZE

   Where:
   POV-L2     = Layer 2 packet overhead: 7 bytes for HDLC encapsulation
   POV-TUNNEL = Packet overhead due to tunneling: 20 bytes IP header
   POV-PPPMUX = Packet overhead for the multiplexed PPP protocol ID:
                1 byte
   SOV-PPPMUX = Per sample overhead of PPPMUX that includes the sample
                length and sometimes the CRTP protocol ID: 1-3 bytes

   For HDLC, the breakeven point is when MUX-SIZE = 6.


5. 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              |             |
      +---+---+---+---+---+---+---+---+             |
      |              IP               |             |
      +---+---+---+---+---+---+---+---+             +
                      |
                      |  IP forwarding
                      |
                      +
      +---+---+---+---+---+---+---+---+             +
      |            Layer 2            |             |
      +---+---+---+---+---+---+---+---+          Physical
      |             Phys              |          Interface
      +---+---+---+---+---+---+---+---+             +


   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.


6. Suggested PPP and L2TP negotiation for TCRTP

   This section describes the PPP negotiation necessary for
   establishing a PPP connection, and the L2TP negotiation necessary
   for establishing an L2TPHC tunnel.
   The negotiation is between two peers: Peer1 and Peer2.

6.1 PPP negotiation necessary for TCRTP

6.1.1 LCP negotiation - RFC1661

6.1.1.1  Link Establishment

           Peer1                       Peer2
           -----                       -----
   Configure-Request (no options) ->
                                   <- Configure-Ack
                                   <- Configure-Request (no options)
   Configure-Ack                  ->


6.1.1.2 Link Tear Down

   Terminate-Request              ->
                                   <- Terminate-Ack


6.1.2 IPCP negotiation -  RFC2509 and [ECRTP]

           Peer1                       Peer2
           -----                       -----
   Configure-Request              ->
     Options:
     IP-Compression-Protocol
       Use protocol 0x61
       and sub-parameters
       as described in
       RFC2509 and [ECRTP]
                                   <- Configure-Ack
                                   <- Configure-Request
                                        Options:
                                        IP-Compression-Protocol
                                          Use protocol 0x61
                                          and sub-parameters
                                          as described in
                                          RFC2509 and [ECRTP]
   Configure-Ack                  ->


6.2 L2TP negotiation necessary for TCRTP -
         RFC2661 and draft-ietf-l2tpext-l2tphc-03.txt

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

6.2.2 Session Establishment

           Peer1                       Peer2
           -----                       -----
   ICRQ                           ->
     Mandatory AVP's:
     Message Type
     Assigned Session ID
     Call Serial Number
     L2TPHC AVP (See draft-ietf-l2tpext-l2tphc-03.txt)
                                   <- ICRP
                                        Mandatory AVP's:
                                        Message Type
                                        Assigned Session ID
                                        L2TPHC AVP
   ICCN                           ->
     Mandatory AVP's:
     Message Type
     Tx (Connect Speed)
     Framing Type
                                   <- ZLB


6.2.3 Tunnel Tear Down

           Peer1                       Peer2
           -----                       -----
   StopCCN                        ->
     Mandatory AVP's:
     Message Type
     Assigned Tunnel ID
     Result Code
                                   <- ZLB


7. Security Considerations

   This draft does not impose additional security considerations beyond
   those that apply to L2TPHC, L2TP, PPP and header-compression schemes
   over PPP.

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

9. References

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

   [PPPMUX] R. Pazhyannur, I. Ali, "PPP Multiplexed Frame Option",
   draft-ietf-pppext-pppmux-03.txt, February 2001.

   [ECRTP] T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy,
   "Enhancements to IP/UDP/RTP Header
   Compression", draft-ietf-avt-crtp-enhance-02.txt, July 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.

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


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

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