idnits 2.17.1 draft-ietf-avt-tcrtp-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 666 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'L2TPHC' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'PPPMUX' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'ECRTP' is defined on line 566, but no explicit reference was found in the text == Unused Reference: 'CRTP' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'IPHCOMP' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'IPCPHC' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RTP' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'L2TP' is defined on line 583, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-l2tpext-l2tphc-02 -- Possible downref: Normative reference to a draft: ref. 'L2TPHC' == Outdated reference: A later version (-03) exists of draft-ietf-pppext-pppmux-00 == Outdated reference: A later version (-07) exists of draft-ietf-avt-crtp-enhance-00 ** Obsolete normative reference: RFC 2509 (ref. 'IPCPHC') (Obsoleted by RFC 3544) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio/Video Transport Working Group Bruce Thompson 2 Internet Draft Tmima Koren 3 July 12, 2000 Dan Wing 4 Expires March 2001 Cisco Systems 5 draft-ietf-avt-tcrtp-01.txt 7 Tunneling multiplexed Compressed RTP ("TCRTP") 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsolete by other documents 19 at any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2000). All Rights Reserved. 32 1. Abstract 34 This document describes a method to improve the end-to-end bandwidth 35 utilization of RTP streams over an IP network using compression and 36 multiplexing. Several application level compression/multiplexing 37 solutions have been evaluated so far in the IETF AVT Working Group. 38 This proposal differs from other solutions in that neither compression 39 nor multiplexing needs to be done at application level. Because of 40 this, existing RTP based applications do not need to change to support 41 this encapsulation format. 43 Instead of proposing a new encapsulation format for end to end 44 multiplexing, this document describes the application of existing 45 protocols for compression, multiplexing, and end to end tunneling. 47 2. Introduction 49 This document describes the application of existing protocols for 50 compression, multiplexing, and end to end tunneling that can be used by 51 RTP applications to implement an end to end multiplexing scheme for RTP 52 transport. Header Compression is used to reduce the header overhead of 53 a single RTP payload. Tunneling is used to transport compressed headers 54 and payloads through a multiple hop IP network without having to 55 compress and decompress at each link. Multiplexing is used to reduce 56 the overhead of tunnel headers by amortizing a single tunnel header 57 over many RTP payloads. 59 For compression, this document proposes the use of RFC 2508 based RTP 60 header compression (CRTP). RFC 2508 describes the use of RTP header 61 compression on an unspecified link layer transport. Most CRTP 62 implementations use PPP as the link layer transport for the session. 63 PPP has been integrated with a number of physical link layer protocols 64 such as HDLC. When PPP is integrated with a physical link layer for 65 CRTP transport, it has the disadvantage that headers must be compressed 66 and decompressed at each IP hop in an end to end network. 68 A CRTP session can be made to work across multiple IP hops to enable 69 end to end compression by tunneling the PPP session. The tunneling 70 protocol proposed by this document is L2TP (RFC 2661). L2TP is a 71 general tunneling protocol for PPP sessions. Since PPP is used as the 72 link layer protocol for CRTP, the extensions described in RFC 2509 are 73 required to negotiate the CRTP session. 75 When the overhead of a tunnel header is added to a single compressed 76 RTP payload, there is very little bandwidth savings when compared to 77 uncompressed transport of RTP streams. Multiplexing is required to 78 amortize the overhead of the tunnel header over many RTP payloads. The 79 multiplexing format that is proposed by this document is PPP 80 multiplexing (Draft-ietf-pppext-pppmux-00.txt). PPP multiplexing allows 81 many PPP payloads to be encapsulated as a single multiplexed PPP 82 payload. The resulting multiplexed PPP payload can then be transported 83 between two RTP endpoints using L2TP. 85 In order to make end to end transport of CRTP sessions efficient when 86 using L2TP, some extensions are needed to both the CRTP protocol and 87 the L2TP protocol. This document describes extensions that have been 88 proposed for these protocols to make them more efficient when they are 89 used as described in this document. These extensions to CRTP and L2TP 90 have been proposed in separate Internet drafts. 92 3. Protocol Operation and Recommended Extensions 94 3.1. CRTP 96 When CRTP sessions are transported through a network using an L2TP 97 tunnel, some of the basic assumptions used for CRTP over a single 98 physical link may no longer be valid. Tunneling a CRTP session through 99 multiple IP hops may increase the round trip delay and the chance of 100 packet loss. CRTP contexts get invalidated due to packet loss. The CRTP 101 error recovery mechanism using CONTEXT_STATE messages can compound the 102 loss problem when long round trip delays are involved. This is because 103 once the CRTP decompressor context state gets out of sync with the 104 compressor, it will drop packets associated with the context until the 105 two states are resynchronized. Resynchronization involves the 106 transmission of the CONTEXT_STATE message from the decompressor to the 107 compressor, and a FULL_HEADER message from the compressor to the 108 decompressor. 110 Enhancements to CRTP are needed to minimize feedback based error 111 recovery using context state messages. Draft-ietf-avt-crtp-enhance- 112 00.txt proposes CRTP enhancements to make it more tolerant of packet 113 loss, and minimize the need to use the CRTP error recovery mechanism. 114 Specific recommendations for the use of the CRTP protocol when 115 transported through a tunnel are described below. 117 The CU* packet format described in Draft-ietf-avt-crtp-enhance-00.txt 118 should be used to synchronize CRTP compressor and decompressor state 119 whenever the incoming packet stream causes a change in the compressor 120 context state. The CU* packet format allows any portion of the context 121 state to be transmitted from the compressor to the decompressor. 123 To ensure delivery of state changes, CU* packets should be delivered 124 using either the N mode of operation or the ACK mode of operation 125 described in Draft-ietf-avt-crtp-enhance-00.txt. The method that should 126 be used depends on the expected loss rate of packets in the network. 127 Networks with a low loss rate for packets in the tunnel should use the 128 N mode of operation. Networks with a high loss rate should use the ACK 129 mode of operation. 131 UDP checksums should be used for RTP packets transported using TCRTP. 132 The twice algorithm described in RFC 2508 should be used by the CRTP 133 decompressor to resynchronize context state in the event of packet loss 134 within the tunnel. In the event that UDP checksums are not generated by 135 the application, the CRTP compressor should use the CRTP Headers 136 checksum described in Draft-ietf-avt-crtp-enhance-00.txt. 138 Tunneled transport does not guarantee in order delivery of packets. 139 Therefore, the CRTP decompressor must be capable of operation in the 140 presence of out of order packet delivery. A CRTP decompressor may treat 141 out of order delivery the same as packet loss. There is no need to 142 reorder packets that are delivered out of order. 144 3.2 PPP Multiplexing 146 Draft-ietf-pppext-pppmux-00.txt describes an encapsulation that allows 147 combining multiple PPP payloads into one multiplexed payload. The 148 encapsulation format used for PPP multiplexing allows any supported PPP 149 payload type to be multiplexed. 151 Draft-ietf-pppext-pppmux-00.txt describes the logic of an example PPP 152 multiplexing transmitter. When PPP multiplexing is used with an L2TP 153 tunnel, the transmitter will typically not have access to an interface 154 transmit queue. In many PPP multiplexing implementations, the PPP 155 multiplex transmitter will send packets to a tunnel encapsulation 156 module. The tunnel encapsulation module will typically be implemented 157 above the IP layer. This means that when the PPP multiplex transmitter 158 encapsulates packets, the outbound physical interface for the packet 159 will not be known. The result is that in implementations such as this, 160 the PPP multiplex transmission algorithm as described in draft-ietf- 161 pppext-pppmux-00.txt will never multiplex multiple PPP payloads into 162 one multiplex PPP payload. 164 To enable the PPP multiplex transmission algorithm to work properly in 165 tunneled implementations, some modifications to the transmission logic 166 are needed. The transmission logic could be modified to collect 167 incoming payloads to be multiplexed until one of two conditions 168 occurred. The first condition is that a target number (N) of payloads 169 or bytes has arrived at the multiplexer. The second condition is that a 170 timer (T) which bounds delay in the multiplexer has expired. The first 171 condition is used to ensure that the multiplexer encapsulates multiple 172 payloads in the same PPP multiplex payload independent of the method 173 used to hand packets to the next encapsulation layer. The second 174 condition is used to always bound the amount of delay to an acceptable 175 value. Delay due to multiplexing may become unacceptable in cases where 176 there are not enough payloads arriving at the multiplexer to allow the 177 multiplexed packet to be sent in a timely manner using only the first 178 condition. The timer is reset whenever a multiplexed payload is sent to 179 the next encapsulation layer. 181 The optimal values for N and T will vary depending upon the rate at 182 which payloads are expected to arrive at the multiplexer and the amount 183 of acceptable delay allowed in the network. 185 3.3. L2TP 187 L2TP tunnels should be used to tunnel the CRTP payloads end to end. 188 This is a natural choice since CRTP payloads are PPP payloads, and L2TP 189 allows tunneled transport of PPP payloads. L2TP includes methods for 190 tunneling messages used in PPP session establishment such as NCP. This 191 allows the procedures of RFC 2509 to be used for negotiating the use of 192 CRTP within a tunnel and to negotiate compression/decompression 193 parameters to be used for the CRTP session. 195 To get reasonable bandwidth efficiency using multiplexing within an 196 L2TP tunnel, multiple RTP streams must be active between the source and 197 destination of an L2TP tunnel. If the source and destination of the 198 L2TP tunnel are the same as the source and destination of the CRTP 199 sessions, then the source and destination must have multiple active RTP 200 streams to get any benefit from multiplexing. Because of this 201 limitation, TCRTP is mostly useful for applications where many RTP 202 sessions run between a pair of RTP endpoints. The number of 203 simultaneous RTP sessions required to reduce the header overhead to a 204 minimum depends on how big the L2TP header is. A smaller L2TP header 205 will result in fewer simultaneous RTP sessions being required to 206 produce bandwidth efficiencies similar to CRTP. 208 Draft-ietf-l2tpext-l2tphc-00.txt describes a method of compressing L2TP 209 tunnel headers from 36 bytes including the IP header to 21 bytes. 210 L2TPHC packets include an IP header, using an IP protocol that is 211 negotiated between the two hosts at the ends of the L2TP tunnel. The 212 UDP header is omitted, and the L2TPHC header is reduced to 1 byte. The 213 added overhead is now 21 bytes of the combined IP and L2TPHC headers. 215 When L2TP is used to carry CRTP streams, the RTP streams may use the EF 216 DSCP. When an EF packet is tunneled, the tunnel header must be marked 217 as EF. This is a requirement of RFC 2598. To prevent TCRTP tunnels from 218 using excess EF bandwidth, it is recommended that only packets marked 219 with the EF DSCP be transported in the tunnel with EF DSCP. 221 3.4 Encapsulation Formats 223 The packet format for an RTP packet compressed with RTP header 224 compression 225 As defined in RFC 2508 is: 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | | MSTI | | | 229 | Context | | UDP | | 230 | ID | Link | Checksum | RTP Data | 231 | | Sequence| | | 232 | (1-2) | (1) | (0-2) | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 The packet format of a multiplexed PPP packet is as follows: 236 (diagram taken from draft-ietf-pppext-pppmux-00.txt) 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Mux |P| | | | |P| | | | 240 | PPP |F| Len1 | PPP | | |F| LenN | PPP | | 241 | Prot. |F| | Prot. |Info1| ~ |F| | Prot. |InfoN| 242 | Field | (7 bits)| Field1| | | (7 bits)|FieldN | | 243 | (2) |(1 byte )| (0-2) | | |(1 byte) | (0-2) | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 246 The format of an L2TPHC packet with a PPP payload is: 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | IP header | L2TPHC | PPP payload | 250 | | Header | | 251 | (20) | (1) | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 The combined format used for TCRTP with a single payload is: 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | IP hdr|L2TPHC | Mux |P| | | | MSTI| | | 258 | |Header | PPP |F| Len1 | PPP |Context| | UDP |RTP | 259 | (20) | (1) | Prot. |F| | Prot. | ID | Link| Cksum |Data | 260 | | | Field | (7 bits)| Field1| | Seq | | | 261 | | | (2) |(1 byte )| (0-2) | (1-2) | (1) | (1-2) | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 CRTP is defined in RFC2508 266 Extensions to CRTP to make it more tolerant to packet loss are defined 267 in: draft-ietf-avt-crtp-enhance-00.txt. 268 L2TPHC is defined in: draft-ietf-l2tpext-l2tphc-02.txt 270 PPP multiplexing is defined in: draft-ietf-pppext-pppmux-00.txt 272 4. Bandwidth Efficiency 274 The expected bandwidth efficiency attainable with TCRTP depends upon a 275 number of factors. These factors include multiplexing gain, expected 276 loss rate within the tunnel, and rates of change of fields within the 277 IP and RTP headers. This section also describes how TCRTP 278 significantly enhances bandwidth efficiency for voice over IP over ATM. 280 4.1 Multiplexing gains 282 Multiplexing reduces the overhead associated with the layer 2 and 283 tunnel headers. Increasing the number of CRTP payloads combined into 284 one multiplexed PPP payload increases multiplexing gain. As traffic 285 increases within a tunnel, more payloads will be able to be combined in 286 one multiplexed payload. This will increase multiplexing gain. The 287 effect of multiplexing gain on per flow bandwidth will decrease as more 288 payloads are added to the multiplexed payload. 290 4.2 Packet loss rate 292 The expected loss rate in a tunnel will affect the decision of which 293 method is used to indicate state changes. 295 In cases where the loss rate is relatively low (<5%) the "N mode" 296 should be sufficient to ensure delivery of state changes (described in 297 draft-ietf-avt-crtp-enhance-00.txt). The optimal value of N will vary 298 depending on the loss rate in the tunnel. A value of N=2 will protect 299 against the loss of a single packet within a compressed session. A 300 value of N=3 will protect against the loss of two packets in a row 301 within a compressed session and so on. Assuming a random distribution 302 of loss within a single compressed session and tunnel loss rates < 1%, 303 the probability of a loss of two or more packets in a row in a 304 compressed session should be < .01%. For networks with a tunnel loss 305 rate of 1% or less, N=2 should be sufficient to ensure reliable 306 transmission of compression state changes. 308 The other mechanism described in draft-ietf-avt-crtp-enhance-00.txt, 309 "ACK mode", is not described in this document. "ACK mode" is mostly 310 applicable to very lossy networks (>5%). 312 4.3 Changing headers 314 There are two fields in the RTP/UDP/IP header whose deltas are likely 315 to change fairly often. These fields are the RTP Time Stamp and the 316 Identification field in the IP header. 318 4.3.1 Voice Activity Detection 320 For voice applications, voice activity detection will cause an 321 unpredictable gap in the RTP Time Stamp field whenever a new talk spurt 322 begins. This gap in the RTP Time Stamp field will cause a change in the 323 CRTP Time Stamp delta field. To allow all the compressed state 324 information for the RTP Time Stamp field to be updated in the event of 325 packet loss, the new RTP timestamp needs to be delivered at the 326 beginning of a talk spurt. The CU* compressed header format is used to 327 deliver the absolute RTP timestamp. N mode is used to ensure these 328 changes are transmitted from compressor to decompressor. 330 4.3.2 IPID 332 Depending on the implementation of the source node of an RTP flow, the 333 Identification field in the IP header (IPID) can change randomly from 334 packet to packet within a flow. 336 An IP transmitter typically increments the IPID field by a constant 337 value from packet to packet, but the delta IPID between two packets 338 within an RTP flow may actually change by any value. When compressing 339 an RTP stream where the IPID is not incrementing by a constant value, 340 the best way to maintain context synchronization is to use the CU* 341 header format and include the absolute IPID in each compressed packet. 343 4.4 Bandwidth calculation formula 345 The formula below uses the factors that have been described above to 346 come up with a model for per flow bandwidth usage. 348 The following variables are defined: 350 SOV-TCRTP = The per sample overhead of CRTP and the multiplexed PPP 351 header in bytes. This value does not include additional overhead for 352 updating IPID or the RTP Time Stamp fields. The value assumes the use 353 of the COMPRESSED-RTP payload type. It consists of 1 byte for the CRTP 354 context ID, 1 byte for COMPRESSED-RTP flags, 2 bytes for the UDP 355 checksum, 1 byte for PPP protocol ID, and 1 byte for the multiplexed 356 PPP length field. This gives a total of 6 bytes. 358 POV-TCRTP = The per packet overhead of tunneled CRTP in bytes. This is 359 the overhead for the tunnel header and the multiplexed PPP payload 360 type. This value is 20 bytes for the IP header, 1 byte for the L2TPHC 361 header, and 2 bytes for the multiplexed PPP protocol ID. Additional 362 overhead needed to be added for layer 2 encapsulation. For HDLC, the 363 layer 2 overhead would be 7 bytes. This gives a total per packet 364 overhead of 30 bytes. 366 VAD-LENGTH = The average length of a talk spurt for voice streams with 367 voice activity detection enabled. This is typically around 1500 msec. 368 Expressed in milliseconds. 370 SOV-TSTAMP = The additional per sample overhead of the CU* header that 371 includes the absolute time stamp field. This value includes 1 byte for 372 the extra flags field in the CU* header and 2 bytes for the absolute 373 time stamp for a total of 3 bytes. 375 SOV-IPID = The additional per sample overhead of the CU* header that 376 includes the absolute IPID field. This value includes 2 bytes for the 377 absolute IPID. This value also includes 1 byte for the extra flags 378 field in the CU* header. The total is 3 bytes. 380 IPID-RATIO = The frequency that IPID need to be updated. This value is 381 0 or 1. If IPID is changing randomly and always needs to be updated, 382 then IPID-RATIO will be 1. If IPID is changing by a constant amount 383 between samples of a flow, then IPID-RATIO will be 0. 384 N = The value of N for N mode. This is the number of times an update 385 field will be repeated in CRTP headers to increase the delivery rate 386 between the compressor and decompressor. For this example, we will 387 assume N=2. 389 PAYLOAD-SIZE = The size of the voice payload in bytes. 391 MUX-SIZE = The number of PPP payloads to be multiplexed into one 392 multiplexed PPP payload. 394 SAMPLE-PERIOD = The average sample period of all calls in the 395 multiplex. In msec. 397 BANDWIDTH = The average amount of bandwidth used per call. In kbits / 398 sec. 400 SOV-TOTAL = The total amount of per sample overhead associated with 401 tunneled CRTP. It includes the per sample overhead of CRTP and PPP, 402 timestamp update overhead, and IPID update overhead. 404 SOV-TOTAL = SOV-TCRTP + 405 SOV-TSTAMP * (N * SAMPLE-PERIOD / VAD-LENGTH) + 406 SOV-IPID * (N * IPID-RATIO) 408 BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) * 8) 409 / SAMPLE-PERIOD) 411 To create an example using the above formulas, we will assume the 412 following usage scenario. Compressed voice streams using G.729 413 compression with a 20 msec packetization period. In this scenario, VAD 414 is enabled and the average talk spurt length is 1500 msec. The IPID 415 field is changing randomly between payloads of streams. There is enough 416 traffic in the tunnel to allow 3 payloads to be multiplexed in a 417 multiplexed PPP payload. The following values apply: 419 SAMPLE-PERIOD = 20 msec 420 VAD-LENGTH = 1500 msec 421 IPID-RATIO = 1PAYLOAD-SIZE = 20 bytes 422 MUX-SIZE = 3 424 For this example, per call bandwidth is 16 kbits/sec. Non tunneled CRTP 425 using the same factors as above yields 12.8 kbits/sec. 427 The effect of IPID can have a large effect on per call bandwidth. If 428 the above example is recalculated using an IPID-RATIO of 0, then the 429 per call bandwidth is reduced to 14.4 kbits/sec. Non tunneled CRTP 430 using these same factors yields 12 kbits/call. 432 4.5 TCRTP Efficiency for Voice over IP over ATM 434 Layer 2 encapsulation can have a large effect on the amount of 435 bandwidth used with TCRTP encapsulation. Multiplexing gain has a 436 dramatic effect on bandwidth when ATM encapsulation is used. IP 437 transport over AAL-5 causes a quantizing effect to bandwidth 438 utilization. This is because packet sizes will always be in multiples 439 of ATM cell sizes, due to the small sample sizes associated with voice 440 with low bit rate coders. 442 For example, the sample size for a G.729 coder using 10 msec sample 443 rate is 10 bytes. This is much smaller than the payload size of an ATM 444 cell (48 bytes). When standard IP header compression schemes (CRTP) are 445 applied in an ATM environment, the result is VOIP packets that are 446 small. However, AAL-5 encapsulation and the resulting cell padding 447 cause the minimum PDU size to be one ATM cell. 449 Instead of wasting this padding, the multiplexing of TCRTP allows this 450 previously wasted space in the ATM cell to contain useful data. This 451 is one of the main reasons why multiplexing has such a large effect on 452 bandwidth utilization with Voice over IP over ATM. 454 4.6. TCRTP Efficiency for Voice over IP over non-ATM networks 456 When TCRTP is used with other layer 2 encapsulations that do not have a 457 minimum PDU size, the benefits of multiplexing is not as great. 459 Depending upon the exact overhead of the layer 2 encapsulation, the 460 benefits of VOIP multiplexing might be slightly better or worse than 461 link-by-link CRTP header compression. The per sample overhead of CRTP 462 tunneling is either 4 or 6 bytes. If classical CRTP plus layer 2 463 overhead is greater than this amount, VOIP multiplexing will end up 464 having lower bandwidth than classical CRTP when the outer IP header is 465 amortized over a large number of samples. 467 The breakeven point in samples can be determined by the following 468 formula: 469 POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX + 470 SOV-PPPMUX * MUX-SIZE 472 Where: 473 POV-L2 = Layer 2 packet overhead: 7 bytes for HDLC encapsulation 474 POV-TUNNEL = Packet overhead due to tunneling: 20 bytes IP header, 1 475 byte L2TPHC header: 21 bytes 476 POV-PPPMUX = Packet overhead for the multiplexed PPP protocol ID: 477 2 bytes 478 SOV-PPPMUX = Per sample overhead of PPPMUX that includes the sample 479 length and sometimes the CRTP protocol ID: 1-3 bytes 481 For HDLC, the breakeven point is when MUX-SIZE = 6. 483 5. Example implementation of TCRTP 485 This section describes an example implementation of TCRTP. 486 Implementations of TCRTP may be done in many ways as long as the 487 requirements of the associated RFCs are met. 489 Here is the path an RTP packet takes in this implementation: 491 +---+---+---+---+---+---+---+---+ + 492 | Application | | 493 +---+---+---+---+---+---+---+---+ | 494 | RTP | | 495 +---+---+---+---+---+---+---+---+ Application 496 | UDP | | 497 +---+---+---+---+---+---+---+---+ | 498 | IP | | 499 +---+---+---+---+---+---+---+---+ + 500 | 501 | IP forwarding 502 | 503 + 504 +---+---+---+---+---+---+---+---+ + 505 | CRTP | | 506 +---+---+---+---+---+---+---+---+ | 507 | PPPMUX | | 508 +---+---+---+---+---+---+---+---+ Tunnel 509 | PPP | Interface 510 +---+---+---+---+---+---+---+---+ | 511 | L2TP | | 512 +---+---+---+---+---+---+---+---+ | 513 | IP | | 514 +---+---+---+---+---+---+---+---+ + 515 | 516 | IP forwarding 517 | 518 + 519 +---+---+---+---+---+---+---+---+ + 520 | Layer 2 | | 521 +---+---+---+---+---+---+---+---+ Physical 522 | Phys | Interface 523 +---+---+---+---+---+---+---+---+ + 525 A protocol stack is configured to create an L2TP tunnel interface to a 526 destination host. The tunnel is configured to negotiate NCP IPCP with 527 CRTP header compression and PPPMUX. IP forwarding is configured to 528 route packets with the same destination address of the previously 529 configured L2TP tunnel interface to that tunnel interface. To ensure 530 that other traffic destined to the same IP address is not routed to 531 this tunnel interface, the forwarding module should be configured to 532 examine additional information in the IP packet. The destination UDP 533 port number is an example of the additional information that may be 534 used to select the L2TP tunnel interface. 536 The transmitting application gathers the RTP data and formats an RTP 537 packet. Lower level application layers add UDP and IP headers to form a 538 complete IP packet. 540 The RTP packets are routed to the tunnel interface where they are 541 compressed, multiplexed, and tunneled to the destination host. 543 The operation of the receiving node is the same as the transmitting 544 node in reverse. 546 6. Acknowledgements 548 The authors would like to thank the authors of RFC2508, 549 Stephen Casner and Van Jacobson, and the authors of RFC2507, 550 Mikael Degermark, Bjorn Nordgren, and Stephen Pink. 552 The authors would also like to thank Dana Blair, Alex Tweedley, 553 Paddy Ruddy, Francois Le Faucheur, Tim Gleeson, Matt Madison, 554 Hussein Salama, Mallik Tatipamula, Mike Thomas, Mark Townsley, 555 Andrew Valencia, Herb Wildfeuer, J Martin Borden, John Geevarghese, 556 and Shoou Yiu. 558 7. References 560 [L2TPHC] A. Valencia, "L2TP Header Compression ("L2TPHC") ", 561 draft-ietf-l2tpext-l2tphc-02.txt, June 2000. 563 [PPPMUX] R. Pazhyannur, I. Ali, "PPP Multiplexed Frame Option", 564 draft-ietf-pppext-pppmux-00.txt, January 2000. 566 [ECRTP] T. Koren, S. Casner, P. Ruddy, B. Thompson, A. Tweeedly, 567 D. Wing, J. Geevarghese, "Enhancements to IP/UDP/RTP Header 568 Compression", draft-ietf-avt-crtp-enhance-00.txt, June 2000. 570 [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 571 Low-Speed Serial Links", RFC2508, February 1999. 573 [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, 574 "IP Header Compression", RFC2507, February 1999. 576 [IPCPHC] M. Engan, S. Casner, C. Bormann, 577 "IP Header Compression over PPP", RFC2509, February 1999. 579 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A 580 Transport Protocol for Real-Time Applications", RFC1889, 581 January 1996. 583 [L2TP] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, 584 B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC2661, 585 August 1999. 587 8. Authors' Addresses 589 Bruce Thompson 590 170 West Tasman Drive 591 San Jose, CA 95134-1706 592 United States of America 594 Phone: +1 408 527 0446 595 Email: brucet@cisco.com 597 Tmima Koren 598 170 West Tasman Drive 599 San Jose, CA 95134-1706 600 United States of America 602 Phone: +1 408 527 6169 603 Email: tmima@cisco.com 605 Dan Wing 606 170 West Tasman Drive 607 San Jose, CA 95134-1706 608 United States of America 610 Phone: +1 408 525 5314 611 Email: dwing@cisco.com 613 9. Full Copyright Statement 615 Copyright (C) The Internet Society (2000). All Rights Reserved. 617 This document and translations of it may be copied and furnished to 618 others, and derivative works that comment on or otherwise explain it 619 or assist in its implementation may be prepared, copied, published 620 and distributed, in whole or in part, without restriction of any 621 kind, provided that the above copyright notice and this paragraph 622 are included on all such copies and derivative works. However, this 623 document itself may not be modified in any way, such as by removing 624 the copyright notice or references to the Internet Society or other 625 Internet organizations, except as needed for the purpose of 626 developing Internet standards in which case the procedures for 627 copyrights defined in the Internet Standards process must be 628 followed, or as required to translate it into languages other than 629 English. 631 The limited permissions granted above are perpetual and will not be 632 revoked by the Internet Society or its successors or assigns. 634 This document and the information contained herein is provided on an 635 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 636 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 637 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 638 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 639 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.