idnits 2.17.1 draft-ietf-avt-tcrtp-02.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 770 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 657, but no explicit reference was found in the text == Unused Reference: 'PPPMUX' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'ECRTP' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'CRTP' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'IPHCOMP' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'IPCPHC' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RTP' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'L2TP' is defined on line 681, 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-01 == Outdated reference: A later version (-07) exists of draft-ietf-avt-crtp-enhance-01 ** 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 November 20, 2000 Dan Wing 4 Expires June 2001 Cisco Systems 5 draft-ietf-avt-tcrtp-02.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. This document describes the application of existing 37 protocols for compression, multiplexing, and end to end tunneling. 39 2. Introduction 41 This document describes the application of existing protocols for 42 compression, multiplexing, and end to end tunneling that can be used by 43 RTP applications to implement an end to end multiplexing scheme for RTP 44 transport. Header Compression is used to reduce the header overhead of 45 a single RTP payload. Tunneling is used to transport compressed headers 46 and payloads through a multiple hop IP network without having to 47 compress and decompress at each link. Multiplexing is used to reduce 48 the overhead of tunnel headers by amortizing a single tunnel header 49 over many RTP payloads. 51 For compression, this document proposes the use of RFC 2508 based RTP 52 header compression (CRTP). RFC 2508 describes the use of RTP header 53 compression on an unspecified link layer transport. Most CRTP 54 implementations use PPP as the link layer transport for the session. 55 PPP has been integrated with a number of physical link layer protocols 56 such as HDLC. When PPP is integrated with a physical link layer for 57 CRTP transport, it has the disadvantage that headers must be compressed 58 and decompressed at each IP hop in an end to end network. 60 A CRTP session can be made to work across multiple IP hops to enable 61 end to end compression by tunneling the PPP session. The tunneling 62 protocol proposed by this document is L2TP (RFC 2661). L2TP is a 63 general tunneling protocol for PPP sessions. Since PPP is used as the 64 link layer protocol for CRTP, the extensions described in RFC 2509 are 65 required to negotiate the CRTP session. 67 When the overhead of a tunnel header is added to a single compressed 68 RTP payload, there is very little bandwidth savings when compared to 69 uncompressed transport of RTP streams. Multiplexing is required to 70 amortize the overhead of the tunnel header over many RTP payloads. The 71 multiplexing format that is proposed by this document is PPP 72 multiplexing (Draft-ietf-pppext-pppmux-00.txt). PPP multiplexing allows 73 many PPP payloads to be encapsulated as a single multiplexed PPP 74 payload. The resulting multiplexed PPP payload can then be transported 75 between two RTP endpoints using L2TP. 77 In order to make end to end transport of CRTP sessions efficient when 78 using L2TP, some extensions are needed to both the CRTP protocol and 79 the L2TP protocol. This document describes extensions that have been 80 proposed for these protocols to make them more efficient when they are 81 used as described in this document. These extensions to CRTP and L2TP 82 have been proposed in separate Internet drafts. 84 3. Protocol Operation and Recommended Extensions 86 3.1. CRTP 88 When CRTP sessions are transported through a network using an L2TP 89 tunnel, some of the basic assumptions used for CRTP over a single 90 physical link may no longer be valid. Tunneling a CRTP session through 91 multiple IP hops may increase the round trip delay and the chance of 92 packet loss. CRTP contexts get invalidated due to packet loss. The CRTP 93 error recovery mechanism using CONTEXT_STATE messages can compound the 94 loss problem when long round trip delays are involved. This is because 95 once the CRTP decompressor context state gets out of sync with the 96 compressor, it will drop packets associated with the context until the 97 two states are resynchronized. Resynchronization involves the 98 transmission of the CONTEXT_STATE message from the decompressor to the 99 compressor, and a FULL_HEADER message from the compressor to the 100 decompressor. 102 Enhancements to CRTP are needed to minimize feedback based error 103 recovery using context state messages. Draft-ietf-avt-crtp-enhance- 104 01.txt proposes CRTP enhancements to make it more tolerant of packet 105 loss, and minimize the need to use the CRTP error recovery mechanism. 106 Specific recommendations for the use of the CRTP protocol when 107 transported through a tunnel are described below. 109 The CU* packet format described in Draft-ietf-avt-crtp-enhance-01.txt 110 should be used to synchronize CRTP compressor and decompressor state 111 whenever the incoming packet stream causes a change in the compressor 112 context state. The CU* packet format allows any portion of the context 113 state to be transmitted from the compressor to the decompressor. 115 To ensure delivery of state changes, CU* packets should be delivered 116 using either the N mode of operation or the ACK mode of operation 117 described in Draft-ietf-avt-crtp-enhance-01.txt. The method that should 118 be used depends on the expected loss rate of packets in the network. 119 Networks with a low loss rate for packets in the tunnel should use the 120 N mode of operation. Networks with a high loss rate should use the ACK 121 mode of operation. 123 UDP checksums should be used for RTP packets transported using TCRTP. 124 The twice algorithm described in RFC 2508 should be used by the CRTP 125 decompressor to resynchronize context state in the event of packet loss 126 within the tunnel. In the event that UDP checksums are not generated by 127 the application, the CRTP compressor should use the CRTP Headers 128 checksum described in Draft-ietf-avt-crtp-enhance-01.txt. 130 Tunneled transport does not guarantee in order delivery of packets. 131 Therefore, the CRTP decompressor must be capable of operation in the 132 presence of out of order packet delivery. A CRTP decompressor may treat 133 out of order delivery the same as packet loss. There is no need to 134 reorder packets that are delivered out of order. 136 3.2 PPP Multiplexing 138 Draft-ietf-pppext-pppmux-01.txt describes an encapsulation that allows 139 combining multiple PPP payloads into one multiplexed payload. The 140 encapsulation format used for PPP multiplexing allows any supported PPP 141 payload type to be multiplexed. 143 Draft-ietf-pppext-pppmux-01.txt describes the logic of an example PPP 144 multiplexing transmitter. When PPP multiplexing is used with an L2TP 145 tunnel, the transmitter will typically not have access to an interface 146 transmit queue. In many PPP multiplexing implementations, the PPP 147 multiplex transmitter will send packets to a tunnel encapsulation 148 module. The tunnel encapsulation module will typically be implemented 149 above the IP layer. This means that when the PPP multiplex transmitter 150 encapsulates packets, the outbound physical interface for the packet 151 will not be known. The result is that in implementations such as this, 152 the PPP multiplex transmission algorithm as described in draft-ietf- 153 pppext-pppmux-01.txt will never multiplex multiple PPP payloads into 154 one multiplex PPP payload. 156 To enable the PPP multiplex transmission algorithm to work properly in 157 tunneled implementations, some modifications to the transmission logic 158 are needed. The transmission logic could be modified to collect 159 incoming payloads to be multiplexed until one of two conditions 160 occurred. The first condition is that a target number (N) of payloads 161 or bytes has arrived at the multiplexer. The second condition is that a 162 timer (T) which bounds delay in the multiplexer has expired. The first 163 condition is used to ensure that the multiplexer encapsulates multiple 164 payloads in the same PPP multiplex payload independent of the method 165 used to hand packets to the next encapsulation layer. The second 166 condition is used to always bound the amount of delay to an acceptable 167 value. Delay due to multiplexing may become unacceptable in cases where 168 there are not enough payloads arriving at the multiplexer to allow the 169 multiplexed packet to be sent in a timely manner using only the first 170 condition. The timer is reset whenever a multiplexed payload is sent to 171 the next encapsulation layer. 173 The optimal values for N and T will vary depending upon the rate at 174 which payloads are expected to arrive at the multiplexer and the amount 175 of acceptable delay allowed in the network. 177 3.3. L2TP 179 L2TP tunnels should be used to tunnel the CRTP payloads end to end. 180 This is a natural choice since CRTP payloads are PPP payloads, and L2TP 181 allows tunneled transport of PPP payloads. L2TP includes methods for 182 tunneling messages used in PPP session establishment such as NCP. This 183 allows the procedures of RFC 2509 to be used for negotiating the use of 184 CRTP within a tunnel and to negotiate compression/decompression 185 parameters to be used for the CRTP session. 187 To get reasonable bandwidth efficiency using multiplexing within an 188 L2TP tunnel, multiple RTP streams must be active between the source and 189 destination of an L2TP tunnel. If the source and destination of the 190 L2TP tunnel are the same as the source and destination of the CRTP 191 sessions, then the source and destination must have multiple active RTP 192 streams to get any benefit from multiplexing. Because of this 193 limitation, TCRTP is mostly useful for applications where many RTP 194 sessions run between a pair of RTP endpoints. The number of 195 simultaneous RTP sessions required to reduce the header overhead to a 196 minimum depends on how big the L2TP header is. A smaller L2TP header 197 will result in fewer simultaneous RTP sessions being required to 198 produce bandwidth efficiencies similar to CRTP. 200 Draft-ietf-l2tpext-l2tphc-00.txt describes a method of compressing L2TP 201 tunnel headers from 36 bytes including the IP header to 21 bytes. 202 L2TPHC packets include an IP header, using an IP protocol that is 203 negotiated between the two hosts at the ends of the L2TP tunnel. The 204 UDP header is omitted, and the L2TPHC header is reduced to 1 byte. The 205 added overhead is now 21 bytes of the combined IP and L2TPHC headers. 207 When L2TP is used to carry CRTP streams, the RTP streams may use the EF 208 DSCP. When an EF packet is tunneled, the tunnel header must be marked 209 as EF. This is a requirement of RFC 2598. To prevent TCRTP tunnels from 210 using excess EF bandwidth, it is recommended that only packets marked 211 with the EF DSCP be transported in the tunnel with EF DSCP. 213 3.4 Encapsulation Formats 215 The packet format for an RTP packet compressed with RTP header 216 compression 217 As defined in RFC 2508 is: 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | MSTI | | | 221 | Context | | UDP | | 222 | ID | Link | Checksum | RTP Data | 223 | | Sequence| | | 224 | (1-2) | (1) | (0-2) | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 The packet format of a multiplexed PPP packet is as follows: 228 (diagram taken from draft-ietf-pppext-pppmux-01.txt) 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Mux |P L| | | | |P L| | | | 232 | PPP |F X|Len1 | PPP | | |F X|LenN | PPP | | 233 | Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN| 234 | Field | | Field1| | | |FieldN | | 235 | (1) |1-2 bytes| (0-2) | | |1-2 bytes| (0-2) | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 238 The format of an L2TPHC packet with a PPP payload is: 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | IP header | L2TPHC | PPP payload | 242 | | Header | | 243 | (20) | (1) | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 The combined format used for TCRTP with a single payload is: 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | IP hdr|L2TPHC | Mux |P L| | | | MSTI| | | 250 | |Header | PPP |F X|Len1 | PPP |Context| | UDP |RTP | 251 | (20) | (1) | Prot. |F T| | Prot. | ID | Link| Cksum |Data | 252 | | | Field | | Field1| | Seq | | | 253 | | | (1) |1-2 bytes| (0-2) | (1-2) | (1) | (0-2) | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 CRTP is defined in RFC2508 258 Extensions to CRTP to make it more tolerant to packet loss are defined 259 in: draft-ietf-avt-crtp-enhance-01.txt. 260 L2TPHC is defined in: draft-ietf-l2tpext-l2tphc-02.txt 262 PPP multiplexing is defined in: draft-ietf-pppext-pppmux-01.txt 264 4. Bandwidth Efficiency 266 The expected bandwidth efficiency attainable with TCRTP depends upon a 267 number of factors. These factors include multiplexing gain, expected 268 loss rate within the tunnel, and rates of change of fields within the 269 IP and RTP headers. This section also describes how TCRTP 270 significantly enhances bandwidth efficiency for voice over IP over ATM. 272 4.1 Multiplexing gains 274 Multiplexing reduces the overhead associated with the layer 2 and 275 tunnel headers. Increasing the number of CRTP payloads combined into 276 one multiplexed PPP payload increases multiplexing gain. As traffic 277 increases within a tunnel, more payloads will be able to be combined in 278 one multiplexed payload. This will increase multiplexing gain. The 279 effect of multiplexing gain on per flow bandwidth will decrease as more 280 payloads are added to the multiplexed payload. 282 4.2 Packet loss rate 284 The expected loss rate in a tunnel will affect the decision of which 285 method is used to indicate state changes. 287 In cases where the loss rate is relatively low (<5%) the "N mode" 288 should be sufficient to ensure delivery of state changes (described in 289 draft-ietf-avt-crtp-enhance-01.txt). The optimal value of N will vary 290 depending on the loss rate in the tunnel. A value of N=2 will protect 291 against the loss of a single packet within a compressed session. A 292 value of N=3 will protect against the loss of two packets in a row 293 within a compressed session and so on. Assuming a random distribution 294 of loss within a single compressed session and tunnel loss rates < 1%, 295 the probability of a loss of two or more packets in a row in a 296 compressed session should be < .01%. For networks with a tunnel loss 297 rate of 1% or less, N=2 should be sufficient to ensure reliable 298 transmission of compression state changes. 300 The other mechanism described in draft-ietf-avt-crtp-enhance-01.txt, 301 "ACK mode", is not described in this document. "ACK mode" is mostly 302 applicable to very lossy networks (>5%). 304 4.3 Changing headers 306 There are two fields in the RTP/UDP/IP header whose deltas are likely 307 to change fairly often. These fields are the RTP Time Stamp and the 308 Identification field in the IP header. 310 4.3.1 Voice Activity Detection 312 For voice applications, voice activity detection will cause an 313 unpredictable gap in the RTP Time Stamp field whenever a new talk spurt 314 begins. This gap in the RTP Time Stamp field will cause a change in the 315 CRTP Time Stamp delta field. To allow all the compressed state 316 information for the RTP Time Stamp field to be updated in the event of 317 packet loss, the new RTP timestamp needs to be delivered at the 318 beginning of a talk spurt. The CU* compressed header format is used to 319 deliver the absolute RTP timestamp. N mode is used to ensure these 320 changes are transmitted from compressor to decompressor. 322 4.3.2 IPID 324 Depending on the implementation of the source node of an RTP flow, the 325 Identification field in the IP header (IPID) can change randomly from 326 packet to packet within a flow. 328 An IP transmitter typically increments the IPID field by a constant 329 value from packet to packet, but the delta IPID between two packets 330 within an RTP flow may actually change by any value. When compressing 331 an RTP stream where the IPID is not incrementing by a constant value, 332 the best way to maintain context synchronization is to use the CU* 333 header format and include the absolute IPID in each compressed packet. 335 4.4 Bandwidth calculation formula 337 The formula below uses the factors that have been described above to 338 come up with a model for per flow bandwidth usage. 340 The following variables are defined: 342 SOV-TCRTP = The per sample overhead of CRTP and the multiplexed PPP 343 header in bytes. This value does not include additional overhead for 344 updating IPID or the RTP Time Stamp fields. The value assumes the use 345 of the COMPRESSED-RTP payload type. It consists of 1 byte for the CRTP 346 context ID, 1 byte for COMPRESSED-RTP flags, 2 bytes for the UDP 347 checksum, 1 byte for PPP protocol ID, and 1 byte for the multiplexed 348 PPP length field. This gives a total of 6 bytes. 350 POV-TCRTP = The per packet overhead of tunneled CRTP in bytes. This is 351 the overhead for the tunnel header and the multiplexed PPP payload 352 type. This value is 20 bytes for the IP header, 1 byte for the L2TPHC 353 header, and 2 bytes for the multiplexed PPP protocol ID. Additional 354 overhead needed to be added for layer 2 encapsulation. For HDLC, the 355 layer 2 overhead would be 7 bytes. This gives a total per packet 356 overhead of 30 bytes. 358 VAD-LENGTH = The average length of a talk spurt for voice streams with 359 voice activity detection enabled. This is typically around 1500 msec. 360 Expressed in milliseconds. 362 SOV-TSTAMP = The additional per sample overhead of the CU* header that 363 includes the absolute time stamp field. This value includes 1 byte for 364 the extra flags field in the CU* header and 2 bytes for the absolute 365 time stamp for a total of 3 bytes. 367 SOV-IPID = The additional per sample overhead of the CU* header that 368 includes the absolute IPID field. This value includes 2 bytes for the 369 absolute IPID. This value also includes 1 byte for the extra flags 370 field in the CU* header. The total is 3 bytes. 372 IPID-RATIO = The frequency that IPID need to be updated. This value is 373 0 or 1. If IPID is changing randomly and always needs to be updated, 374 then IPID-RATIO will be 1. If IPID is changing by a constant amount 375 between samples of a flow, then IPID-RATIO will be 0. 377 N = The value of N for N mode. This is the number of times an update 378 field will be repeated in CRTP headers to increase the delivery rate 379 between the compressor and decompressor. For this example, we will 380 assume N=2. 382 PAYLOAD-SIZE = The size of the voice payload in bytes. 384 MUX-SIZE = The number of PPP payloads to be multiplexed into one 385 multiplexed PPP payload. 387 SAMPLE-PERIOD = The average sample period of all calls in the 388 multiplex. In msec. 390 BANDWIDTH = The average amount of bandwidth used per call. In kbits / 391 sec. 393 SOV-TOTAL = The total amount of per sample overhead associated with 394 tunneled CRTP. It includes the per sample overhead of CRTP and PPP, 395 timestamp update overhead, and IPID update overhead. 397 SOV-TOTAL = SOV-TCRTP + 398 SOV-TSTAMP * (N * SAMPLE-PERIOD / VAD-LENGTH) + 399 SOV-IPID * (N * IPID-RATIO) 401 BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) * 8) 402 / SAMPLE-PERIOD) 404 To create an example using the above formulas, we will assume the 405 following usage scenario. Compressed voice streams using G.729 406 compression with a 20 msec packetization period. In this scenario, VAD 407 is enabled and the average talk spurt length is 1500 msec. The IPID 408 field is changing randomly between payloads of streams. There is enough 409 traffic in the tunnel to allow 3 payloads to be multiplexed in a 410 multiplexed PPP payload. The following values apply: 412 SAMPLE-PERIOD = 20 msec 413 VAD-LENGTH = 1500 msec 414 IPID-RATIO = 1 415 PAYLOAD-SIZE = 20 bytes 416 MUX-SIZE = 3 418 For this example, per call bandwidth is 16 kbits/sec. Non tunneled CRTP 419 over a single HDLC link using the same factors as above yields 12.8 420 kbits/sec. 422 The effect of IPID can have a large effect on per call bandwidth. If 423 the above example is recalculated using an IPID-RATIO of 0, then the 424 per call bandwidth is reduced to 14.4 kbits/sec. Non tunneled CRTP over 425 a single HDLC link using these same factors yields 12 kbits/call. 427 4.5 TCRTP Efficiency for Voice over IP over ATM 429 Layer 2 encapsulation can have a large effect on the amount of 430 bandwidth used with TCRTP encapsulation. Multiplexing gain has a 431 dramatic effect on bandwidth when ATM encapsulation is used. IP 432 transport over AAL-5 causes a quantizing effect to bandwidth 433 utilization. This is because packet sizes will always be in multiples 434 of ATM cell sizes, due to the small sample sizes associated with voice 435 with low bit rate coders. 437 For example, the sample size for a G.729 coder using 10 msec sample 438 rate is 10 bytes. This is much smaller than the payload size of an ATM 439 cell (48 bytes). When standard IP header compression schemes (CRTP) are 440 applied in an ATM environment, the result is VOIP packets that are 441 small. However, AAL-5 encapsulation and the resulting cell padding 442 cause the minimum PDU size to be one ATM cell. 444 Instead of wasting this padding, the multiplexing of TCRTP allows this 445 previously wasted space in the ATM cell to contain useful data. This 446 is one of the main reasons why multiplexing has such a large effect on 447 bandwidth utilization with Voice over IP over ATM. 449 4.6. TCRTP Efficiency for Voice over IP over non-ATM networks 451 When TCRTP is used with other layer 2 encapsulations that do not have a 452 minimum PDU size, the benefits of multiplexing is not as great. 454 Depending upon the exact overhead of the layer 2 encapsulation, the 455 benefits of VOIP multiplexing might be slightly better or worse than 456 link-by-link CRTP header compression. The per sample overhead of CRTP 457 tunneling is either 4 or 6 bytes. If classical CRTP plus layer 2 458 overhead is greater than this amount, VOIP multiplexing will end up 459 having lower bandwidth than classical CRTP when the outer IP header is 460 amortized over a large number of samples. 462 The breakeven point in samples can be determined by the following 463 formula: 464 POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX + 465 SOV-PPPMUX * MUX-SIZE 467 Where: 468 POV-L2 = Layer 2 packet overhead: 7 bytes for HDLC encapsulation 469 POV-TUNNEL = Packet overhead due to tunneling: 20 bytes IP header, 1 470 byte L2TPHC header: 21 bytes 471 POV-PPPMUX = Packet overhead for the multiplexed PPP protocol ID: 472 1 byte 473 SOV-PPPMUX = Per sample overhead of PPPMUX that includes the sample 474 length and sometimes the CRTP protocol ID: 1-3 bytes 476 For HDLC, the breakeven point is when MUX-SIZE = 6. 478 5. Example implementation of TCRTP 480 This section describes an example implementation of TCRTP. 481 Implementations of TCRTP may be done in many ways as long as the 482 requirements of the associated RFCs are met. 484 Here is the path an RTP packet takes in this implementation: 486 +---+---+---+---+---+---+---+---+ + 487 | Application | | 488 +---+---+---+---+---+---+---+---+ | 489 | RTP | | 490 +---+---+---+---+---+---+---+---+ Application 491 | UDP | | 492 +---+---+---+---+---+---+---+---+ | 493 | IP | | 494 +---+---+---+---+---+---+---+---+ + 495 | 496 | IP forwarding 497 | 498 + 499 +---+---+---+---+---+---+---+---+ + 500 | CRTP | | 501 +---+---+---+---+---+---+---+---+ | 502 | PPPMUX | | 503 +---+---+---+---+---+---+---+---+ Tunnel 504 | PPP | Interface 505 +---+---+---+---+---+---+---+---+ | 506 | L2TP | | 507 +---+---+---+---+---+---+---+---+ | 508 | IP | | 509 +---+---+---+---+---+---+---+---+ + 510 | 511 | IP forwarding 512 | 513 + 514 +---+---+---+---+---+---+---+---+ + 515 | Layer 2 | | 516 +---+---+---+---+---+---+---+---+ Physical 517 | Phys | Interface 518 +---+---+---+---+---+---+---+---+ + 520 A protocol stack is configured to create an L2TP tunnel interface to a 521 destination host. The tunnel is configured to negotiate NCP IPCP with 522 CRTP header compression and PPPMUX. IP forwarding is configured to 523 route packets with the same destination address of the previously 524 configured L2TP tunnel interface to that tunnel interface. To ensure 525 that other traffic destined to the same IP address is not routed to 526 this tunnel interface, the forwarding module should be configured to 527 examine additional information in the IP packet. The destination UDP 528 port number is an example of the additional information that may be 529 used to select the L2TP tunnel interface. 531 The transmitting application gathers the RTP data and formats an RTP 532 packet. Lower level application layers add UDP and IP headers to form a 533 complete IP packet. 535 The RTP packets are routed to the tunnel interface where they are 536 compressed, multiplexed, and tunneled to the destination host. 538 The operation of the receiving node is the same as the transmitting 539 node in reverse. 541 6. Suggested PPP and L2TP negotiation for TCRTP 543 This section describes the PPP negotiation necessary for establishing a 544 PPP connection, and the L2TP negotiation necessary for establishing an 545 L2TPHC tunnel. 546 The negotiation is between two peers: Peer1 and Peer2. 548 6.1 PPP negotiation necessary for TCRTP 550 6.1.1 LCP negotiation - RFC1661 552 6.1.1.1 Link Establishment 554 Peer1 Peer2 555 ----- ----- 556 Configure-Request (no options) -> 557 <- Configure-Ack 558 <- Configure-Request (no options) 559 Configure-Ack -> 561 6.1.1.2 Link Tear Down 563 Terminate-Request -> 564 <- Terminate-Ack 566 6.1.2 IPCP negotiation - RFC1332 and RFC2509 568 Peer1 Peer2 569 ----- ----- 570 Configure-Request -> 571 Option: 572 IP-Compression-Protocol 573 Use protocol 0x61 574 and sub-parameters 575 as described in RFC2509 576 <- Configure-Ack 577 <- Configure-Request 578 Option: IP-Compression-Protocol 579 Use protocol 0x61 580 and sub-parameters 581 as described in RFC2509 582 Configure-Ack -> 584 6.2 L2TP negotiation necessary for TCRTP - 585 RFC2661 and draft-ietf-l2tpext-l2tphc-02.txt 587 6.2.1 Tunnel Establishment 589 Peer1 Peer2 590 ----- ----- 591 SCCRQ -> 592 Mandatory AVP's: 593 Message Type 594 Protocol Version 595 Host Name 596 Framing Capabilities 597 Assigned Tunnel ID 598 <- SCCRP 599 Mandatory AVP's: 600 Message Type 601 Protocol Version 602 Host Name 603 Framing Capabilities 604 Assigned Tunnel ID 605 SCCCN -> 606 Mandatory AVP's: 607 Message Type 608 <- ZLB 610 6.2.2 Session Establishment 612 Peer1 Peer2 613 ----- ----- 614 ICRQ -> 615 Mandatory AVP's: 616 Message Type 617 Assigned Session ID 618 Call Serial Number 619 L2TPHC AVP (See draft-ietf-l2tpext-l2tphc-02.txt) 620 <- ICRP 621 Mandatory AVP's: 622 Message Type 623 Assigned Session ID 624 L2TPHC AVP 625 ICCN -> 626 Mandatory AVP's: 627 Message Type 628 Tx (Connect Speed) 629 Framing Type 630 <- ZLB 632 6.2.3 Tunnel Tear Down 634 Peer1 Peer2 635 ----- ----- 636 StopCCN -> 637 Mandatory AVP's: 638 Message Type 639 Assigned Tunnel ID 640 Result Code 641 <- ZLB 643 7. Acknowledgements 645 The authors would like to thank the authors of RFC2508, 646 Stephen Casner and Van Jacobson, and the authors of RFC2507, 647 Mikael Degermark, Bjorn Nordgren, and Stephen Pink. 649 The authors would also like to thank Dana Blair, Alex Tweedley, 650 Paddy Ruddy, Francois Le Faucheur, Tim Gleeson, Matt Madison, 651 Hussein Salama, Mallik Tatipamula, Mike Thomas, Mark Townsley, 652 Andrew Valencia, Herb Wildfeuer, J Martin Borden, John Geevarghese, 653 and Shoou Yiu. 655 8. References 657 [L2TPHC] A. Valencia, "L2TP Header Compression ("L2TPHC") ", 658 draft-ietf-l2tpext-l2tphc-02.txt, June 2000. 660 [PPPMUX] R. Pazhyannur, I. Ali, "PPP Multiplexed Frame Option", 661 draft-ietf-pppext-pppmux-01.txt, October 2000. 663 [ECRTP] T. Koren, S. Casner, P. Ruddy, B. Thompson, A. Tweeedly, 664 D. Wing, J. Geevarghese, "Enhancements to IP/UDP/RTP Header 665 Compression", draft-ietf-avt-crtp-enhance-01.txt, 666 November 2000. 668 [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 669 Low-Speed Serial Links", RFC2508, February 1999. 671 [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, 672 "IP Header Compression", RFC2507, February 1999. 674 [IPCPHC] M. Engan, S. Casner, C. Bormann, 675 "IP Header Compression over PPP", RFC2509, February 1999. 677 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A 678 Transport Protocol for Real-Time Applications", RFC1889, 679 January 1996. 681 [L2TP] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, 682 B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC2661, 683 August 1999. 685 9. Authors' Addresses 687 Bruce Thompson 688 170 West Tasman Drive 689 San Jose, CA 95134-1706 690 United States of America 692 Phone: +1 408 527 0446 693 Email: brucet@cisco.com 695 Tmima Koren 696 170 West Tasman Drive 697 San Jose, CA 95134-1706 698 United States of America 700 Phone: +1 408 527 6169 701 Email: tmima@cisco.com 703 Dan Wing 704 170 West Tasman Drive 705 San Jose, CA 95134-1706 706 United States of America 708 Phone: +1 408 525 5314 709 Email: dwing@cisco.com 711 10. Full Copyright Statement 713 Copyright (C) The Internet Society (2000). All Rights Reserved. 715 This document and translations of it may be copied and furnished to 716 others, and derivative works that comment on or otherwise explain it 717 or assist in its implementation may be prepared, copied, published 718 and distributed, in whole or in part, without restriction of any 719 kind, provided that the above copyright notice and this paragraph 720 are included on all such copies and derivative works. However, this 721 document itself may not be modified in any way, such as by removing 722 the copyright notice or references to the Internet Society or other 723 Internet organizations, except as needed for the purpose of 724 developing Internet standards in which case the procedures for 725 copyrights defined in the Internet Standards process must be 726 followed, or as required to translate it into languages other than 727 English. 729 The limited permissions granted above are perpetual and will not be 730 revoked by the Internet Society or its successors or assigns. 732 This document and the information contained herein is provided on an 733 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 734 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 735 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 736 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 737 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.