Audio/Video Transport Working Group Bruce Thompson Internet Draft Tmima Koren File: 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]