idnits 2.17.1 draft-ietf-avt-tcrtp-06.txt: 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([PPP], [PPP-MUX], [RFCXXXX], [L2TP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- The document date (February 27, 2002) is 8094 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ECRTP' is mentioned on line 455, but not defined == Unused Reference: 'RTP' is defined on line 880, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-l2tpext-l2tphc-04 -- Possible downref: Normative reference to a draft: ref. 'L2TP-HC' == Outdated reference: A later version (-07) exists of draft-ietf-avt-crtp-enhance-04 ** Obsolete normative reference: RFC 2509 (ref. 'IPCP-HC') (Obsoleted by RFC 3544) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2598 (ref. 'EF-PHB') (Obsoleted by RFC 3246) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group Bruce Thompson 3 Internet Draft Tmima Koren 4 File: Dan Wing 5 Cisco Systems 6 Expires: September 2002 February 27, 2002 8 Tunneling Multiplexed Compressed RTP ("TCRTP") 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsolete by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2001). All Rights Reserved. 33 Note to RFC Editor: 35 Please replace [RFCXXXX] by the RFC number that will be allocated to 36 draft-ietf-avt-crtp-enhance-04.txt 38 Abstract 40 This document describes a method to improve the end-to-end bandwidth 41 utilization of RTP streams over an IP network using compression and 42 multiplexing. This is accomplished by combining three standard 43 protocols: Enhanced CRTP [RFCXXXX] for header compression, PPP [PPP] 44 Multiplexing [PPP-MUX] for multiplexing, and L2TP tunneling [L2TP] 45 for transmission of PPP over an IP network. 47 TCRTP February 2002 49 Table of Contents 51 1. Introduction.......................................................3 52 1.1. Is Bandwidth Costly?.............................................3 53 1.2. Overview of Protocols............................................3 54 1.3. Document Focus...................................................4 55 1.4. Enhanced CRTP....................................................4 56 1.5. Reducing TCRTP Overhead..........................................4 57 2. Protocol Operation and Recommended Extensions......................4 58 2.1. Models...........................................................4 59 2.2. Header Compression: ECRTP........................................5 60 2.2.1. Synchronizing ECRTP States....................................5 61 2.2.2. Out-of-Order Packets..........................................6 62 2.3. Multiplexing: PPP Multiplexing...................................6 63 2.3.1. PPP Multiplex Transmitter Modifications for Tunneling.........6 64 2.3.2. Tunneling Inefficiencies......................................8 65 2.4. Tunneling: L2TP..................................................8 66 2.4.1. Compressing L2TP headers......................................8 67 2.4.2. Tunneling and DiffServ........................................8 68 2.5. Encapsulation Formats............................................9 69 3. Bandwidth Efficiency..............................................10 70 3.1. Multiplexing gains..............................................10 71 3.2. Packet loss rate................................................10 72 3.3. Bandwidth Calculation for Voice Applications....................10 73 3.3.1. Bandwidth Calculation Example................................12 74 3.3.2. Bandwidth Comparison Table...................................12 75 3.3.3. Voice over IP over ATM.......................................13 76 3.3.4. Voice over IP over non-ATM networks..........................13 77 4. Example implementation of TCRTP...................................14 78 4.1. Suggested PPP and L2TP negotiation for TCRTP....................16 79 4.2. PPP negotiation TCRTP...........................................16 80 4.2.1. LCP negotiation..............................................16 81 4.2.2. IPCP negotiation.............................................16 82 4.3. L2TP negotiation................................................17 83 4.3.1. Tunnel Establishment.........................................17 84 4.3.2. Session Establishment........................................17 85 4.3.3. Tunnel Tear Down.............................................18 86 5. IANA Considerations...............................................18 87 6. Security Considerations...........................................18 88 7. Acknowledgements..................................................19 89 8. References........................................................19 90 9. Authors' Addresses................................................20 91 10. Full Copyright Statement.........................................21 92 TCRTP February 2002 94 1. Introduction 96 This document describes a way to combine existing protocols for 97 compression, multiplexing, and tunneling to save bandwidth for RTP 98 applications. 100 1.1. Is Bandwidth Costly? 102 On certain links, such as customer access links, the cost of 103 bandwidth is widely acknowledged. Protocols such as CRTP [CRTP] are 104 well suited to help bandwidth inefficiencies of protocols such as 105 VoIP over these links. 107 Unacknowledged by many, however, is the cost of long-distance WAN 108 links. While some voice-over-packet technologies such as Voice over 109 ATM (VoAAL2, [I.363.2]) and Voice over MPLS provide bandwidth 110 efficiencies because both technologies lack IP, UDP, and RTP headers, 111 neither VoATM nor VoMPLS provide direct access to voice-over-packet 112 services available to Voice over IP. Thus, goals of WAN link cost 113 reduction are met at the expense of lost interconnection 114 opportunities to other networks. 116 TCRTP solves the VoIP bandwidth discrepency, especially for large 117 voice trunking applications. 119 1.2. Overview of Protocols 121 Header compression is accomplished using Enhanced CRTP (ECRTP) 122 described in [RFCXXXX]. ECRTP is an enhancement to classical CRTP 123 [CRTP] that works better over long delay links, such as the end-to-end 124 tunneling links described in this document. This header compression 125 reduces the IP, UDP, and RTP headers. 127 Multiplexing is accomplished using PPP Multiplexing [PPP-MUX]. 129 Tunneling PPP is accomplished by using L2TP [L2TP]. 131 CRTP operates link-by-link; that is, to achieve compression over 132 multiple router hops, CRTP must be employed twice on each router -- 133 once on ingress, again on egress. In contrast, TCRTP described in 134 this document does not require any additional per-router processing 135 to achieve header compression -- instead, headers are compressed end- 136 to-end, saving bandwidth on all intermediate links. 138 TCRTP February 2002 140 1.3. Document Focus 142 This document is primarily concerned with bandwidth savings for Voice 143 over IP (VoIP) applications. However, the combinations of protocols 144 described in this document can be used to provide similar bandwidth 145 savings for other RTP applications such as video. 147 1.4. Enhanced CRTP 149 CRTP [CRTP] describes the use of RTP header compression on an 150 unspecified link layer transport, but typically PPP is used. For 151 CRTP to compress headers, it must be implemented on each PPP link. A 152 lot of context is required to successfully run CRTP, and memory and 153 processing requirements are high, especially if multiple hops must 154 implement CRTP to save bandwidth on each of the hops. At higher line 155 rates, CRTP's processor consumption becomes prohibitively expensive. 157 A simplistic solution is to use CRTP with L2TP to achieve end-to-end 158 CRTP. However, as described in [RFCXXXX], CRTP is only suitable for 159 links with low delay and low loss. 161 See section 2.2 for details. 163 1.5. Reducing TCRTP Overhead 165 If only one stream is tunneled (L2TP) and compressed (ECRTP) there is 166 little bandwidth savings. Multiplexing is helpful to amortize the 167 overhead of the tunnel header over many RTP payloads. The 168 multiplexing format that is proposed by this document is PPP 169 multiplexing [PPP-MUX]. See section 2.3 for details. 171 [L2TP-HC] should be used to reduce the size of L2TP headers. See 172 section 2.4 for details. 174 2. Protocol Operation and Recommended Extensions 176 This section describes how to combine three protocols: Enhanced CRTP, 177 PPP Multiplexing, and L2TP Tunneling, to save bandwidth for RTP 178 applications such as Voice over IP. 180 2.1. Models 182 TCRTP can typically be implemented in two ways. The most 183 straightforward is to implement TCRTP in the gateways terminating the 184 RTP streams: 186 TCRTP February 2002 188 [voice gateway]---[voice gateway] 189 ^ 190 | 191 TCRTP over IP 193 Another way TCRTP can be implemented is with an external 194 concentration device. This device could be placed at strategic 195 places in the network and could dynamically create and destroy TCRTP 196 sessions without the participation of RTP-generating endpoints. 198 [voice gateway]\ /[voice gateway] 199 [voice gateway]---[concentrator]---[concentrator]---[voice gateway] 200 [voice gateway]/ \[voice gateway] 201 ^ ^ ^ 202 | | | 203 RTP over IP TCRTP over IP RTP over IP 205 Such a design also allows classical CRTP [CRTP] to be used on links 206 with only a few active flows per link (where TCRTP isn't efficient; 207 see section 3): 209 [voice gateway]\ /[voice gateway] 210 [voice gateway]---[concentrator]---[concentrator]---[voice gateway] 211 [voice gateway]/ \[voice gateway] 212 ^ ^ ^ 213 | | | 214 CRTP over IP TCRTP over IP RTP over IP 216 2.2. Header Compression: ECRTP 218 As described in [RFCXXXX], classical CRTP [CRTP] is not suitable over 219 long-delay links such as the tunneling proposed by this document. 220 Thus, ECRTP should be used. 222 2.2.1. Synchronizing ECRTP States 224 When the compressor receives an RTP packet which has an unpredicted 225 change in the RTP header, the compressor should send a 226 COMPRESSED_UDP packet (described in [RFCXXXX]) to synchronize the ECRTP 227 decompressor state. The COMPRESSED_UDP packet updates the RTP 228 context in the decompressor. 230 To ensure delivery of updates of context variables, COMPRESSED_UDP 231 packets should be delivered using the robust operation described in 232 [RFCXXXX]. 234 TCRTP February 2002 236 As the "twice" algorithm described in [RFCXXXX] relies on UDP 237 checksums, the IP stack on the RTP transmitter should transmit UDP 238 checksums. If UDP checksums are not used, the ECRTP compressor should 239 use the CRTP Headers checksum described in [RFCXXXX]. 241 2.2.2. Out-of-Order Packets 243 Tunneled transport does not guarantee in order delivery of packets. 244 Therefore, the ECRTP decompressor must operate correctly in the 245 presence of out of order packets. 247 2.3. Multiplexing: PPP Multiplexing 249 Both CRTP and ECRTP require a layer two protocol which allows 250 identifying different protocols. [PPP] is suited for this. 252 When CRTP is used inside of a tunnel, the header compression associated 253 with CRTP will reduce the size of the IP, UDP, and IP headers of the IP 254 packet carried in the tunnel. However, the tunnel itself has overhead 255 due to its IP header and the tunnel header (the information necessary 256 to identify the tunneled payload). One way to reduce the overhead of 257 the IP header and tunnel header is to multiplex multiple RTP payloads 258 in a single tunneled packet. 260 [PPP-MUX] describes an encapsulation that combines multiple PPP 261 payloads into one multiplexed payload. PPP multiplexing allows any 262 supported PPP payload type to be multiplexed. This multiplexed frame is 263 then carried as a single PPPMUX payload in the IP tunnel. This allows 264 multiple RTP payloads to be carried in a single IP tunnel packet and 265 allows the overhead of the uncompressed IP and tunnel headers to be 266 amortized over multiple RTP payloads. 268 During PPP establishment of the TCRTP tunnel, only LCP and IPCP (for 269 header compression) are required -- IP addresses do not need to be 270 negotiated, nor is authentication necessary. See section 4.1 for 271 details. 273 2.3.1. PPP Multiplex Transmitter Modifications for Tunneling 275 Section 1.2 of [PPP-MUX] describes an example transmitter procedure that can 276 be used to implement a PPP Multiplex transmitter. The transmission procedure 277 described in this section includes a parameter MAX-SF-LEN that is used to 278 limit the maximum size of a PPP Multiplex frame. 280 There are two reasons for limiting the size of a PPP Multiplex frame. First, a 281 PPPMUX frame should never exceed the MRU of a physical link. Second, when a 282 PPP session and its associated flow control are bound to a physical link, the 283 MAX-SF-LEN parameter forms an upper limit on the amount of time a multiplex 284 packet can be held before being transmitted. When flow control for the PPP 285 Multiplex transmitter is bound to a physical link, the clock rate of the 286 physical link can be used to pull frames from the PPP Multiplex transmitter. 288 TCRTP February 2002 290 This type of flow control limits the maximum amount of time a PPP multiplex 291 frame can be held before being transmitted to MAX-SF-LEN / Link Speed. 293 Tunnel interfaces are typically not bound to physical interfaces. Because of 294 this, a tunnel interface has no well-known transmission rate associated with 295 it. This means that flow control in the PPPMUX transmitter cannot rely on the 296 clock of a physical link to pull frames from the multiplex transmitter. 297 Instead, a timer must be used to limit the amount of time a PPPMUX frame can 298 be held before being transmitted. The timer along with the MAX-SF-LEN 299 parameter should be used to limit the amount of time a PPPMUX frame is held 300 before being transmitted. 302 The following extensions to the PPPMUX transmitter logic should be made 303 for use with tunnels. The flow control logic of the PPP transmitter 304 should be modified to collect incoming payloads until one of two events 305 has occurred: 307 (1) a specific number of octets, MAX-SF-LEN, has arrived at the 308 multiplexer, or; 310 (2) a timer, called T, has expired. 312 When either condition is satisfied, the multiplexed PPP payload is 313 transmitted. 315 The purpose of MAX-SF-LEN is to ensure that a PPPMUX payload does not 316 exceed the MTU size of any of the possible physical links that the 317 tunnel can be associated with. The value of MAX-SF-LEN should be less 318 than or equal to the minimum of MRU-2(maximum size of length field) and 319 16,383 (14 bits) for all possible physical interfaces that the tunnel 320 may be associated with. 322 The timer T provides an upper delay bound for tunnel interfaces. Timer 323 T is reset whenever a multiplexed payload is sent to the next 324 encapsulation layer. The behavior of this timer is similar to AAL2's 325 Timer_CU described in [I.363.2]. Each PPPMUX transmitter should have 326 its own Timer T. 328 TCRTP February 2002 330 The optimal values for T will vary depending upon the rate at which 331 payloads are expected to arrive at the multiplexer and the delay budget 332 for the multiplexing function. For voice applications, the value of T 333 would typically be 5-10 milliseconds. 335 2.3.2. Tunneling Inefficiencies 337 To get reasonable bandwidth efficiency using multiplexing within an 338 L2TP tunnel, multiple RTP streams should be active between the source 339 and destination of an L2TP tunnel. 341 If the source and destination of the L2TP tunnel are the same as the 342 source and destination of the ECRTP sessions, then the source and 343 destination must have multiple active RTP streams to get any benefit 344 from multiplexing. 346 Because of this limitation, TCRTP is mostly useful for applications 347 where many RTP sessions run between a pair of RTP endpoints. The 348 number of simultaneous RTP sessions required to reduce the header 349 overhead to the desired level depends on the size of the L2TP header. 350 A smaller L2TP header will result in fewer simultaneous RTP sessions 351 being required to produce bandwidth efficiencies similar to CRTP. 353 2.4. Tunneling: L2TP 355 L2TP tunnels should be used to tunnel the ECRTP payloads end to end. 356 L2TP includes methods for tunneling messages used in PPP session 357 establishment such as NCP. This allows [IPCP-HC] to negotiate ECRTP 358 compression/decompression parameters. 360 2.4.1. Compressing L2TP headers 362 [L2TP-HC] describes a method of compressing L2TP tunnel headers from 363 36 octets (including the IP header) to 20 octets. L2TP Header 364 Compressed packets include an IP header with the L2TPHC protocol ID, 365 and omit the UDP and L2TP headers. The result is the overhead of the 366 L2TP tunnel is only 20 octets. 368 L2TP header compression is negotiated during tunnel establishment. 369 Its use is recommended as it substantially increases the efficiency 370 of TCRTP. 372 2.4.2. Tunneling and DiffServ 374 RTP streams may be marked with Expedited Forwarding (EF) bits, as 375 described in [EF-PHB]. When such a packet is tunneled, the tunnel 376 header must also be marked for the same EF bits, as required by [EF- 377 PHB]. It is important to not mix EF and non-EF traffic in the same 378 EF-marked multiplexed tunnel. 380 TCRTP February 2002 382 2.5. Encapsulation Formats 384 The packet format for an RTP packet compressed with RTP header 385 compression as defined in ECRTP is: 387 +---------+---------+-------------+-----------------------+ 388 | | MSTI | | | 389 | Context | | UDP | | 390 | ID | Link | Checksum | RTP Data | 391 | | Sequence| | | 392 | (1-2) | (1) | (0-2) | | 393 +---------+---------+-------------+-----------------------+ 395 The packet format of a multiplexed PPP packet as defined by [PPP-MUX] 396 is: 398 +-------+---+------+-------+-----+ +---+------+-------+-----+ 399 | Mux |P L| | | | |P L| | | | 400 | PPP |F X|Len1 | PPP | | |F X|LenN | PPP | | 401 | Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN| 402 | Field | | Field1| | | |FieldN | | 403 | (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | | 404 +-------+----------+-------+-----+ +----------+-------+-----+ 406 The format of an L2TP Header Compressed packet with a PPP payload as 407 defined by [L2TP-HC] is: 409 +-------------------+---------------------------------| 410 | IP header | PPP payload | 411 | (20) | | 412 +-------------------+---------------------------------+ 414 The combined format used for TCRTP with a single payload is all of 415 the above packets concatenated. Here is an example with one payload: 417 +------+-------+----------+-------+-------+-----+-------+----+ 418 | IP | Mux |P L| | | | MSTI| | | 419 |header| PPP |F X|Len1 | PPP |Context| | UDP |RTP | 420 | (20) | Proto |F T| | Proto | ID | Link| Cksum |Data| 421 | | Field | | Field1| | Seq | | | 422 | | (1) |1-2 octets| (0-2) | (1-2) | (1) | (0-2) | | 423 +------+-------+----------+-------+-------+-----+-------+----+ 424 |<------------- IP payload ------------------------->| 425 |<----- PPPmux payload --------------------->| 427 If the tunnel contains multiplexed traffic, multiple "PPPMux 428 payload"s are transmitted in one IP packet. 430 TCRTP February 2002 432 3. Bandwidth Efficiency 434 The expected bandwidth efficiency attainable with TCRTP depends upon 435 a number of factors. These factors include multiplexing gain, 436 expected packet loss rate across the network, and rates of change of 437 specific fields within the IP and RTP headers. This section also 438 describes how TCRTP significantly enhances bandwidth efficiency for 439 voice over IP over ATM. 441 3.1. Multiplexing gains 443 Multiplexing reduces the overhead associated with the layer 2 and 444 tunnel headers. Increasing the number of CRTP payloads combined into 445 one multiplexed PPP payload increases multiplexing gain. As traffic 446 increases within a tunnel, more payloads are combined in one 447 multiplexed payload. This will increase multiplexing gain. 449 3.2. Packet loss rate 451 Loss of a multiplexed packet causes packet loss for all of the flows 452 within the multiplexed packet. 454 When the expected loss rate in a tunnel is relatively low (less than 455 perhaps 5%), the robust operation (described in [ECRTP]) should be 456 sufficient to ensure delivery of state changes. This robust operation 457 is characterized by a parameter N which means that the probability of 458 more than N adjacent packets getting lost on the tunnel is small. 460 A value of N=1 will protect against the loss of a single packet 461 within a compressed session at the expense of bandwidth. A value of 462 N=2 will protect against the loss of two packets in a row within a 463 compressed session and so on. Higher values of N have higher bandwidth 464 penalties. 466 The optimal value of N will depend on the loss rate in the tunnel. 468 If the loss rate is high (above perhaps 5%) more advanced techniques 469 must be employed. Those techniques are beyond the scope of this 470 document. 472 3.3. Bandwidth Calculation for Voice Applications 474 The following formula uses the factors described above to model per- 475 flow bandwidth usage. These variables are defined: 477 SOV-TCRTP, unit: octet. Per-payload overhead of ECRTP and the 478 multiplexed PPP header. This value does not include additional 479 overhead for updating IP ID or the RTP Time Stamp fields (see 480 [RFCXXXX] for details on IP ID). The value assumes the use of the 481 COMPRESSED_RTP payload type. It consists of 1 octet for the 482 ECRTP context ID, 1 octet for COMPRESSED_RTP flags, 2 octets for 483 TCRTP February 2002 485 the UDP checksum, 1 octet for PPP protocol ID, and 1 octet for 486 the multiplexed PPP length field. The total is 6 octets. 488 POV-TCRTP, unit: octet. Per-packet overhead of tunneled ECRTP. 489 This is the overhead for the tunnel header and the multiplexed 490 PPP payload type. This value is 20 octets for the IP header, 491 and 1 octet for the multiplexed PPP protocol ID. The total is 21 492 octets. 494 TRANSMIT-LENGTH, unit: milliseconds. The average duration of a 495 transmission (such as a talk spurt for voice streams). 497 SOV-TSTAMP, unit: octet. Additional per-payload overhead of the 498 COMPRESSED_UDP header that includes the absolute time stamp 499 field. This value includes 1 octet for the extra flags field in 500 the COMPRESSED_UDP header and 4 octets for the absolute time 501 stamp for a total of 5 octets. 503 SOV-IPID, unit: octet. Additional per-payload overhead of the 504 COMPRESSED_UDP header that includes the absolute IPID field. 505 This value includes 2 octets for the absolute IPID. This value 506 also includes 1 octet for the extra flags field in the 507 COMPRESSED_UDP header. The total is 3 octets. 509 IPID-RATIO, unit: integer values 0 or 1. Indicates the frequency 510 at which IPID will be updated by the compressor. If IPID is 511 changing randomly and thus always needs to be updated, then the 512 value is 1. If IPID is changing by a fixed constant amount 513 between payloads of a flow, then IPID-RATIO will be 0. The value 514 of this variable does not consider the IPID value at the 515 beginning of a voice talk spurts, as that is considered by the 516 variable TRANSMIT-LENGTH. The implementation of the sending 517 IP stack and RTP application controls this behavior. 518 See section 1.1. 520 NREP, unit: integer (usually a number between 1 and 3). This is 521 the number of times an update field will be repeated in ECRTP 522 headers to increase the delivery rate between the compressor and 523 decompressor. For this example, we will assume NREP=2. 525 PAYLOAD-SIZE, unit: octets. The size of the RTP payload in octets. 527 MUX-SIZE, unit: count. The number of PPP payloads multiplexed 528 into one multiplexed PPP payload. 530 SAMPLE-PERIOD, unit: milliseconds. The average delay between 531 transmissions of a voice payload for all calls in the 532 multiplex. The value of this variable is 10ms if all calls 533 have a 10ms sample period. 535 TCRTP February 2002 537 The formula is: 539 SOV-TOTAL = SOV-TCRTP + SOV-TSTAMP * (NREP * SAMPLE-PERIOD / 540 TRANSMIT-LENGTH) + SOV-IPID * IPID-RATIO 542 BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) * 543 8) / SAMPLE-PERIOD) 545 The results are: 547 BANDWIDTH, unit: kilobits per second. The average amount of 548 bandwidth used per call. 550 SOV-TOTAL = The total amount of per-payload overhead associated 551 with tunneled ECRTP. It includes the per-payload overhead of 552 ECRTP and PPP, timestamp update overhead, and IPID update 553 overhead. 555 3.3.1. Bandwidth Calculation Example 557 To create an example using the above formulas, we will assume the 558 following usage scenario. Compressed voice streams using G.729 559 compression with a 20 millisecond packetization period. In this 560 scenario, VAD is enabled and the average talk spurt length is 1500 561 milliseconds. The IPID field is changing randomly between payloads 562 of streams. There is enough traffic in the tunnel to allow 3 563 multiplexed payloads. The following values apply: 565 SAMPLE-PERIOD = 20 milliseconds 566 TRANSMIT-LENGTH = 1500 milliseconds 567 IPID-RATIO = 1 568 PAYLOAD-SIZE = 20 octets 569 MUX-SIZE = 3 571 For this example, per call bandwidth is 14.4 kbits/sec. Classical 572 CRTP over a single HDLC link using the same factors as above yields 573 12.4 kbits/sec. 575 The effect of IPID can have a large effect on per call bandwidth. If 576 the above example is recalculated using an IPID-RATIO of 0, then the 577 per call bandwidth is reduced to 13.2 kbits/sec. Classical CRTP over 578 a single HDLC link using these same factors yields 11.2 kbits/call. 580 3.3.2. Bandwidth Comparison Table 581 TCRTP February 2002 583 Using 5 simultaneous calls, no voice activity detection (VAD), G.729 584 with 20ms packetization interval, not considering RTCP overhead: 586 Normal VoIP over PPP: 124kbps 587 with classical CRTP on a link: 50kbps (savings: 59%) 588 with TCRTP over PPP: 56kbps (savings: 55%) 589 with TCRTP over AAL5: 85kbps (savings: 31%) 591 3.3.3. Voice over IP over ATM 593 IP transport over AAL5 causes a quantizing effect to bandwidth 594 utilization due to the packets always being multiples of ATM cells. 596 For example, the payload size for G.729 using 10 millisecond 597 packetization interval is 10 octets. This is much smaller than the 598 payload size of an ATM cell (48 octets). When classical CRTP [CRTP] 599 is used on a link-by-link basis, the IP overhead to payload ratio is 600 quite good. However, AAL5 encapsulation and its cell padding always 601 force the minimum payload size to be one ATM cell, which results in 602 poor bandwidth utilization. 604 Instead of wasting this padding, the multiplexing of TCRTP allows 605 this previously wasted space in the ATM cell to contain useful data. 606 This is one of the main reasons why multiplexing has such a large 607 effect on bandwidth utilization with Voice over IP over ATM. 609 This multiplexing efficiency of TCRTP is similar to AAL2 sub-cell 610 multiplexing described in [I.363.1]. Unlike AAL2 sub-cell 611 multiplexing, however, TCRTP's multiplexing efficiency isn't limited 612 to only ATM networks. 614 3.3.4. Voice over IP over non-ATM networks 616 When TCRTP is used with other layer 2 encapsulations that do not have 617 a minimum PDU size, the benefit of multiplexing is not as great. 619 Depending upon the exact overhead of the layer 2 encapsulation, the 620 benefit of VOIP multiplexing might be slightly better or worse than 621 link-by-link CRTP header compression. The per-payload overhead of 622 CRTP tunneling is either 4 or 6 octets. If classical CRTP plus layer 623 2 overhead is greater than this amount, TCRTP multiplexing will 624 consume less bandwidth than classical CRTP when the outer IP header 625 is amortized over a large number of payloads. 627 TCRTP February 2002 629 The payload breakeven point can be determined by the following 630 formula: 632 POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + 633 POV-PPPMUX + SOV-PPPMUX * MUX-SIZE 635 Where: 637 POV-L2, unit: octet. Layer 2 packet overhead: 5 octets for HDLC 638 encapsulation 640 POV-TUNNEL, unit: octet. Packet overhead due to tunneling: 20 641 octets IP header 643 POV-PPPMUX, unit: octet. Packet overhead for the multiplexed PPP 644 protocol ID: 1 octet 646 SOV-PPPMUX, unit: octet. Per-payload overhead of PPPMUX, which is 647 comprised of the payload length field and the ECRTP protocol ID. 648 The value of SOV-PPPMUX is typically 1, 2, or 3. 650 If using HDLC as the layer 2 protocol, the breakeven point using the 651 above formula is when MUX-SIZE = 6. Thus 6 voice calls need to be 652 multiplexed to make TCRTP bandwidth-efficient. 654 4. Example implementation of TCRTP 656 This section describes an example implementation of TCRTP. 657 Implementations of TCRTP may be done in many ways as long as the 658 requirements of the associated RFCs are met. 660 TCRTP February 2002 662 Here is the path an RTP packet takes in this implementation: 664 +-------------------------------+ ^ 665 | Application | | 666 +-------------------------------+ | 667 | RTP | | 668 +-------------------------------+ Application and 669 | UDP | IP stack 670 +-------------------------------+ | 671 | IP | | 672 +-------------------------------+ V 673 | 674 | IP forwarding 675 | 676 +-------------------------------+ ^ 677 | ECRTP | | 678 +-------------------------------+ | 679 | PPPMUX | | 680 +-------------------------------+ Tunnel 681 | PPP | Interface 682 +-------------------------------+ | 683 | L2TP | | 684 +-------------------------------+ | 685 | IP | | 686 +-------------------------------+ V 687 | 688 | IP forwarding 689 | 690 +-------------------------------+ ^ 691 | Layer 2 | | 692 +-------------------------------+ Physical 693 | Physical | Interface 694 +-------------------------------+ V 696 A protocol stack is configured to create an L2TP tunnel interface to 697 a destination host. The tunnel is configured to negotiate the PPP 698 connection (using NCP IPCP) with ECRTP header compression and PPPMUX. 699 IP forwarding is configured to route RTP packets to this tunnel. The 700 destination UDP port number could distinguish RTP packets from non- 701 RTP packets. 703 The transmitting application gathers the RTP data from one source, 704 and formats an RTP packet. Lower level application layers add UDP and 705 IP headers to form a complete IP packet. 707 The RTP packets are routed to the tunnel interface where headers are 708 compressed, payloads multiplexed, and then tunneled to the 709 destination host. 711 The operation of the receiving node is the same as the transmitting 712 node in reverse. 714 TCRTP February 2002 716 4.1. Suggested PPP and L2TP negotiation for TCRTP 718 This section describes the necessary PPP and LT2P negotiations 719 necessary for establishing a PPP connection and L2TP tunnel with L2TP 720 header compression. 721 The negotiation is between two peers: Peer1 and Peer2. 723 4.2. PPP negotiation TCRTP 725 The Point-to-Point Protocol is described in [PPP]. 727 4.2.1. LCP negotiation 729 Link Control Processing (LCP) is described in [PPP]. 731 4.2.1.1. Link Establishment 733 Peer1 Peer2 734 ----- ----- 735 Configure-Request (no options) -> 736 <- Configure-Ack 737 <- Configure-Request (no options) 738 Configure-Ack -> 740 4.2.1.2. Link Tear Down 742 Terminate-Request -> 743 <- Terminate-Ack 745 4.2.2. IPCP negotiation 747 The protocol exchange here is described in [IPHCOMP], [PPP], and 748 [RFCXXXX]. 750 TCRTP February 2002 752 Peer1 Peer2 753 ----- ----- 754 Configure-Request -> 755 Options: 756 IP-Compression-Protocol 757 Use protocol 0x61 758 and sub-parameters 759 as described in 760 [IPCP-HC] and [RFCXXXX] 761 <- Configure-Ack 762 <- Configure-Request 763 Options: 764 IP-Compression-Protocol 765 Use protocol 0x61 766 and sub-parameters 767 as described in 768 [IPCP-HC] and [RFCXXXX] 769 Configure-Ack -> 771 4.3. L2TP negotiation 773 L2TP is described in [L2TP], and L2TP header compression is described 774 in [L2TP-HC]. 776 4.3.1. Tunnel Establishment 778 Peer1 Peer2 779 ----- ----- 780 SCCRQ -> 781 Mandatory AVP's: 782 Message Type 783 Protocol Version 784 Host Name 785 Framing Capabilities 786 Assigned Tunnel ID 787 <- SCCRP 788 Mandatory AVP's: 789 Message Type 790 Protocol Version 791 Host Name 792 Framing Capabilities 793 Assigned Tunnel ID 794 SCCCN -> 795 Mandatory AVP's: 796 Message Type 797 <- ZLB 799 TCRTP February 2002 801 4.3.2. Session Establishment 803 Peer1 Peer2 804 ----- ----- 805 ICRQ -> 806 Mandatory AVP's: 807 Message Type 808 Assigned Session ID 809 Call Serial Number 810 L2TP-HC AVP [L2TP-HC] 811 <- ICRP 812 Mandatory AVP's: 814 Message Type 815 Assigned Session ID 816 L2TP-HC AVP 817 ICCN -> 818 Mandatory AVP's: 819 Message Type 820 Tx (Connect Speed) 821 Framing Type 822 <- ZLB 824 4.3.3. Tunnel Tear Down 826 Peer1 Peer2 827 ----- ----- 828 StopCCN -> 829 Mandatory AVP's: 830 Message Type 831 Assigned Tunnel ID 832 Result Code 833 <- ZLB 835 5. IANA Considerations 837 This document does not require any assignments from IANA. 839 6. Security Considerations 841 This draft does not impose additional security considerations beyond 842 those that apply to L2TP, PPP and ECRTP. 844 TCRTP February 2002 846 7. Acknowledgements 848 The authors would like to thank the authors of RFC2508, Stephen 849 Casner and Van Jacobson, and the authors of RFC2507, Mikael 850 Degermark, Bjorn Nordgren, and Stephen Pink. 852 The authors would also like to thank Dana Blair, Alex Tweedley, Paddy 853 Ruddy, Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein 854 Salama, Mallik Tatipamula, Mike Thomas, Mark Townsley, Andrew 855 Valencia, Herb Wildfeuer, J. Martin Borden, John Geevarghese, and 856 Shoou Yiu. 858 8. References 860 [L2TP-HC] A. Valencia, "L2TP Header Compression ("L2TPHC") ", 861 draft-ietf-l2tpext-l2tphc-04.txt, October 2001. 863 [PPP-MUX] R. Pazhyannur, I. Ali, C. Fox, "PPP Multiplexing", RFC3153, 864 August 2001. 866 [RFCXXXX] T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy, 867 "Compressing IP/UDP/RTP headers on links with high delay, packet 868 loss, and reordering", draft-ietf-avt-crtp-enhance-04.txt, 869 February 2002. 871 [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 872 Low-Speed Serial Links", RFC2508, February 1999. 874 [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, "IP Header 875 Compression", RFC2507, February 1999. 877 [IPCP-HC] M. Engan, S. Casner, C. Bormann, "IP Header Compression 878 over PPP", RFC2509, February 1999. 880 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A 881 Transport Protocol for Real-Time Applications", RFC1889, January 882 1996. 884 [L2TP] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. 885 Palter, "Layer Two Tunneling Protocol "L2TP"", RFC2661, August 886 1999. 888 [I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 889 AAL", I.363.2, September 1997. 891 [EF-PHB] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding 892 PHB", RFC2598, June 1999. 894 [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC1661, July 895 1994. 897 TCRTP February 2002 899 9. Authors' Addresses 901 Bruce Thompson 902 170 West Tasman Drive 903 San Jose, CA 95134-1706 904 United States of America 906 Phone: +1 408 527 0446 907 Email: brucet@cisco.com 909 Tmima Koren 910 170 West Tasman Drive 911 San Jose, CA 95134-1706 912 United States of America 914 Phone: +1 408 527 6169 915 Email: tmima@cisco.com 917 Dan Wing 918 170 West Tasman Drive 919 San Jose, CA 95134-1706 920 United States of America 922 Phone: +1 408 525 5314 923 Email: dwing@cisco.com 924 TCRTP February 2002 926 10. Full Copyright Statement 928 Copyright (C) The Internet Society (2001). All Rights Reserved. 930 This document and translations of it may be copied and furnished to 931 others, and derivative works that comment on or otherwise explain it 932 or assist in its implementation may be prepared, copied, published 933 and distributed, in whole or in part, without restriction of any 934 kind, provided that the above copyright notice and this paragraph are 935 included on all such copies and derivative works. However, this 936 document itself may not be modified in any way, such as by removing 937 the copyright notice or references to the Internet Society or other 938 Internet organizations, except as needed for the purpose of 939 developing Internet standards in which case the procedures for 940 copyrights defined in the Internet Standards process must be 941 followed, or as required to translate it into languages other than 942 English. 944 The limited permissions granted above are perpetual and will not be 945 revoked by the Internet Society or its successors or assigns. 947 This document and the information contained herein is provided on an 948 AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 949 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 950 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 951 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 952 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.