idnits 2.17.1 draft-ietf-avt-tcrtp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 29. -- Found old boilerplate from RFC 3978, Section 5.5 on line 993. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1015. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 983), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- 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 : ---------------------------------------------------------------------------- No issues found here. 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: 'L2TP' is defined on line 920, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2509 (ref. 'IPCP-HC') (Obsoleted by RFC 3544) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-14 ** Obsolete normative reference: RFC 2598 (ref. 'EF-PHB') (Obsoleted by RFC 3246) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Bruce Thompson 3 Audio/Video Transport Working Group Tmima Koren 4 INTERNET-DRAFT Dan Wing 5 EXPIRES: February 2005 Cisco Systems 6 September, 2004 8 Tunneling Multiplexed Compressed RTP ("TCRTP") 9 draft-ietf-avt-tcrtp-08.txt 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 5 of RFC3667. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or cite them other than as "work in progress". 26 By submitting this Internet-Draft, I certify that any applicable 27 patent or other IPR claims of which I am aware have been disclosed, 28 and any of which I become aware will be disclosed, in accordance 29 with RFC 3668. 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/lid-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document describes a method to improve the bandwidth 44 utilization of RTP streams over network paths that carry multiple 45 Real-time Transport Protocol (RTP) streams in parallel between two 46 endpoints, as in voice trunking. The method combines standard 47 protocols that provide compression, multiplexing, and tunneling over 48 a network path to reduce the bandwidth used when multiple RTP 49 streams are carried over that path. 51 Table of Contents 53 1. Introduction....................................................3 54 1.1. Is Bandwidth Costly?..........................................3 55 1.2. Overview of Protocols.........................................3 56 1.3. Document Focus................................................3 57 1.4. Choice of Enhanced CRTP.......................................4 58 1.5. Reducing TCRTP Overhead.......................................4 59 2. Protocol Operation and Recommended Extensions...................4 60 2.1. Header Compression: ECRTP.....................................5 61 2.1.1. Synchronizing ECRTP States...................................5 62 2.1.2. Out-of-Order Packets.........................................6 63 2.2. Multiplexing: PPP Multiplexing................................6 64 2.2.1. PPP Multiplex Transmitter Modifications for Tunneling........6 65 2.2.2. Tunneling Inefficiencies.....................................8 66 2.3. Tunneling: L2TP...............................................8 67 2.3.1. Tunneling and DiffServ.......................................8 68 2.4. Encapsulation Formats.........................................8 69 3. Bandwidth Efficiency............................................9 70 3.1. Multiplexing gains............................................9 71 3.2. Packet loss rate.............................................10 72 3.3. Bandwidth calculation for Voice and Video Applications.......10 73 3.3.1. Voice Bandwidth Calculation Example.........................12 74 3.3.2. Voice Bandwidth Comparison Table............................12 75 3.3.3. Video Bandwidth Calculation Example.........................13 76 3.3.4. TCRTP over ATM..............................................13 77 3.3.5. TCRTP over non-ATM networks.................................14 78 4. Example implementation of TCRTP................................14 79 4.1. Suggested PPP and L2TP negotiation for TCRTP.................16 80 4.2. PPP negotiation TCRTP........................................16 81 4.2.1. LCP negotiation.............................................16 82 4.2.2. IPCP negotiation............................................16 83 4.3. L2TP negotiation.............................................17 84 4.3.1. Tunnel Establishment........................................17 85 4.3.2. Session Establishment.......................................17 86 4.3.3. Tunnel Tear Down............................................18 87 5. IANA Considerations............................................18 88 6. Security Considerations........................................18 89 7. Acknowledgements...............................................19 90 8. References.....................................................19 91 9. Authors' Addresses.............................................20 92 10. Copyright Notice...............................................21 93 11. Disclaimers....................................................21 94 1. Introduction 96 This document describes a way to combine existing protocols for 97 compression, multiplexing, and tunneling to save bandwidth for some 98 RTP applications. 100 1.1. Is Bandwidth Costly? 102 On certain links, such as customer access links, the cost of 103 bandwidth is widely acknowledged to be a significant concern. 104 Protocols such as CRTP (Compressed RTP, [CRTP]) are well suited to 105 help bandwidth inefficiencies of protocols such as VoIP over these 106 links. 108 Unacknowledged by many, however, is the cost of long-distance WAN 109 links. While some voice-over-packet technologies such as Voice over 110 ATM (VoAAL2, [I.363.2]) and Voice over MPLS provide bandwidth 111 efficiencies because both technologies lack IP, UDP, and RTP 112 headers, neither VoATM nor VoMPLS provide direct access to voice- 113 over-packet services available to Voice over IP. Thus, goals of WAN 114 link cost reduction are met at the expense of lost interconnection 115 opportunities to other networks. 117 TCRTP solves the VoIP bandwidth discrepancy, especially for large 118 voice trunking applications. 120 1.2. Overview of Protocols 122 Header compression is accomplished using Enhanced CRTP (ECRTP, 123 [ECRTP]). ECRTP is an enhancement to classical CRTP [CRTP] that 124 works better over long delay links, such as the end-to-end tunneling 125 links described in this document. This header compression reduces 126 the IP, UDP, and RTP headers. 128 Multiplexing is accomplished using PPP Multiplexing [PPP-MUX]. 130 Tunneling PPP is accomplished by using L2TP [L2TPv3]. 132 CRTP operates link-by-link; that is, to achieve compression over 133 multiple router hops, CRTP must be employed twice on each router -- 134 once on ingress, again on egress. In contrast, TCRTP described in 135 this document does not require any additional per-router processing 136 to achieve header compression -- instead, headers are compressed 137 end-to-end, saving bandwidth on all intermediate links. 139 1.3. Document Focus 140 This document is primarily concerned with bandwidth savings for 141 Voice over IP (VoIP) applications over high-delay networks. 142 However, the combinations of protocols described in this document 143 can be used to provide similar bandwidth savings for other RTP 144 applications such as video, and bandwidth savings are included for a 145 sample video application. 147 1.4. Choice of 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 To avoid the per-hop expense of CRTP, a simplistic solution is to 158 use CRTP with L2TP to achieve end-to-end CRTP. However, as 159 described in [ECRTP], CRTP is only suitable for links with low delay 160 and low loss. However, once multiple router hops are involved, 161 CRTP's expectation of low delay and low loss can no longer be met. 162 Further, packets can arrive out of order. 164 Therefore, this document describes the use of Enhanced CRTP [ECRTP], 165 which supports high delay, both packet loss, and misordering between 166 the compressor and decompressor. 168 1.5. Reducing TCRTP Overhead 170 If only one stream is tunneled (L2TP) and compressed (ECRTP) there 171 is little bandwidth savings. Multiplexing is helpful to amortize 172 the overhead of the tunnel header over many RTP payloads. The 173 multiplexing format that is proposed by this document is PPP 174 multiplexing [PPP-MUX]. See section 2.3 for details. 176 2. Protocol Operation and Recommended Extensions 178 This section describes how to combine three protocols: Enhanced 179 CRTP, PPP Multiplexing, and L2TP Tunneling, to save bandwidth for 180 RTP applications such as Voice over IP. 182 2.1. Models 184 TCRTP can typically be implemented in two ways. The most 185 straightforward is to implement TCRTP in the gateways terminating 186 the RTP streams: 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 GW]\ /[voice GW] 199 [voice GW]---[concentrator]---[concentrator]---[voice GW] 200 [voice GW]/ \[voice GW] 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 GW]\ /[voice GW] 210 [voice GW]---[concentrator]---[concentrator]---[voice GW] 211 [voice GW]/ \[voice GW] 212 ^ ^ ^ 213 | | | 214 CRTP over IP TCRTP over IP RTP over IP 216 2.2. Header Compression: ECRTP 218 As described in [ECRTP], classical CRTP [CRTP] is not suitable over 219 long-delay WAN links commonly used when tunneling as proposed by 220 this document. Thus, ECRTP should be used instead of CRTP. 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 [ECRTP]) to synchronize the 227 ECRTP 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 [ECRTP]. 234 As the "twice" algorithm described in [ECRTP] relies on UDP 235 checksums, the IP stack on the RTP transmitter should transmit UDP 236 checksums. If UDP checksums are not used, the ECRTP compressor 237 should use the CRTP Headers checksum described in [ECRTP]. 239 2.2.2. Out-of-Order Packets 241 Tunneled transport does not guarantee in order delivery of packets. 242 Therefore, the ECRTP decompressor must operate correctly in the 243 presence of out of order packets. 245 The order of packets for RTP is determined by the RTP sequence 246 number. ECRTP sends short deltas from the RTP seqno, and sends a 247 full value every N packets, where N is an engineered constant tuned 248 to the kind of pipe ECRTP is used for. 250 By contrast, [ROHC] compresses out the sequence number and another 251 layer is necessary for [ROHC] to handle out-of-order delivery of 252 packets over a tunnel [REORDER]. 254 2.3. Multiplexing: PPP Multiplexing 256 Both CRTP and ECRTP require a layer two protocol which allows 257 identifying different protocols. [PPP] is suited for this. 259 When CRTP is used inside of a tunnel, the header compression 260 associated with CRTP will reduce the size of the IP, UDP, and IP 261 headers of the IP packet carried in the tunnel. However, the tunnel 262 itself has overhead due to its IP header and the tunnel header (the 263 information necessary to identify the tunneled payload). One way to 264 reduce the overhead of the IP header and tunnel header is to 265 multiplex multiple RTP payloads in a single tunneled packet. 267 [PPP-MUX] describes an encapsulation that combines multiple PPP 268 payloads into one multiplexed payload. PPP multiplexing allows any 269 supported PPP payload type to be multiplexed. This multiplexed 270 frame is then carried as a single PPPMUX payload in the IP tunnel. 271 This allows multiple RTP payloads to be carried in a single IP 272 tunnel packet and allows the overhead of the uncompressed IP and 273 tunnel headers to be amortized over multiple RTP payloads. 275 During PPP establishment of the TCRTP tunnel, only LCP and IPCP (for 276 header compression) are required -- IP addresses do not need to be 277 negotiated, nor is authentication necessary. See section 4.1 for 278 details. 280 2.3.1. PPP Multiplex Transmitter Modifications for Tunneling 282 Section 1.2 of [PPP-MUX] describes an example transmitter procedure 283 that can be used to implement a PPP Multiplex transmitter. The 284 transmission procedure described in this section includes a 285 parameter MAX-SF-LEN that is used to limit the maximum size of a PPP 286 Multiplex frame. 288 There are two reasons for limiting the size of a PPP Multiplex 289 frame. First, a PPPMUX frame should never exceed the MRU of a 290 physical link. Second, when a PPP session and its associated flow 291 control are bound to a physical link, the MAX-SF-LEN parameter forms 292 an upper limit on the amount of time a multiplex packet can be held 293 before being transmitted. When flow control for the PPP Multiplex 294 transmitter is bound to a physical link, the clock rate of the 295 physical link can be used to pull frames from the PPP Multiplex 296 transmitter. 298 This type of flow control limits the maximum amount of time a PPP 299 multiplex frame can be held before being transmitted to MAX-SF-LEN / 300 Link Speed. 302 Tunnel interfaces are typically not bound to physical interfaces. 303 Because of this, a tunnel interface has no well-known transmission 304 rate associated with it. This means that flow control in the PPPMUX 305 transmitter cannot rely on the clock of a physical link to pull 306 frames from the multiplex transmitter. Instead, a timer must be used 307 to limit the amount of time a PPPMUX frame can be held before being 308 transmitted. The timer along with the MAX-SF-LEN parameter should 309 be used to limit the amount of time a PPPMUX frame is held before 310 being transmitted. 312 The following extensions to the PPPMUX transmitter logic should be 313 made for use with tunnels. The flow control logic of the PPP 314 transmitter should be modified to collect incoming payloads until 315 one of two events has occurred: 317 (1) a specific number of octets, MAX-SF-LEN, has arrived at 318 the multiplexer, or; 320 (2) a timer, called T, has expired. 322 When either condition is satisfied, the multiplexed PPP payload is 323 transmitted. 325 The purpose of MAX-SF-LEN is to ensure that a PPPMUX payload does 326 not exceed the MTU size of any of the possible physical links that 327 the tunnel can be associated with. The value of MAX-SF-LEN should be 328 less than or equal to the minimum of MRU-2(maximum size of length 329 field) and 16,383 (14 bits) for all possible physical interfaces 330 that the tunnel may be associated with. 332 The timer T provides an upper delay bound for tunnel interfaces. 333 Timer T is reset whenever a multiplexed payload is sent to the next 334 encapsulation layer. The behavior of this timer is similar to 335 AAL2's Timer_CU described in [I.363.2]. Each PPPMUX transmitter 336 should have its own Timer T. 338 The optimal values for T will vary depending upon the rate at which 339 payloads are expected to arrive at the multiplexer and the delay 340 budget for the multiplexing function. For voice applications, the 341 value of T would typically be 5-10 milliseconds. 343 2.3.2. Tunneling Inefficiencies 345 To get reasonable bandwidth efficiency using multiplexing within an 346 L2TP tunnel, multiple RTP streams should be active between the 347 source and destination of an L2TP tunnel. 349 If the source and destination of the L2TP tunnel are the same as the 350 source and destination of the ECRTP sessions, then the source and 351 destination must have multiple active RTP streams to get any benefit 352 from multiplexing. 354 Because of this limitation, TCRTP is mostly useful for applications 355 where many RTP sessions run between a pair of RTP endpoints. The 356 number of simultaneous RTP sessions required to reduce the header 357 overhead to the desired level depends on the size of the L2TP 358 header. A smaller L2TP header will result in fewer simultaneous RTP 359 sessions being required to produce bandwidth efficiencies similar to 360 CRTP. 362 2.4. Tunneling: L2TP 364 L2TP tunnels should be used to tunnel the ECRTP payloads end to end. 365 L2TP includes methods for tunneling messages used in PPP session 366 establishment such as NCP. This allows [IPCP-HC] to negotiate ECRTP 367 compression/decompression parameters. 369 2.4.1. Tunneling and DiffServ 371 RTP streams may be marked with Expedited Forwarding (EF) bits, as 372 described in [EF-PHB]. When such a packet is tunneled, the tunnel 373 header must also be marked for the same EF bits, as required by [EF- 374 PHB]. It is important to not mix EF and non-EF traffic in the same 375 EF-marked multiplexed tunnel. 377 2.5. Encapsulation Formats 379 The packet format for an RTP packet compressed with RTP header 380 compression as defined in ECRTP is: 382 +---------+---------+-------------+-----------------------+ 383 | | MSTI | | | 384 | Context | | UDP | | 385 | ID | Link | Checksum | RTP Data | 386 | | Sequence| | | 387 | (1-2) | (1) | (0-2) | | 388 +---------+---------+-------------+-----------------------+ 390 The packet format of a multiplexed PPP packet as defined by [PPP- 391 MUX] is: 393 +-------+---+------+-------+-----+ +---+------+-------+-----+ 394 | Mux |P L| | | | |P L| | | | 395 | PPP |F X|Len1 | PPP | | |F X|LenN | PPP | | 396 | Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN| 397 | Field | | Field1| | | |FieldN | | 398 | (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | | 399 +-------+----------+-------+-----+ +----------+-------+-----+ 401 The combined format used for TCRTP with a single payload is all of 402 the above packets concatenated. Here is an example with one 403 payload: 405 +------+-------+----------+-------+-------+-----+-------+----+ 406 | IP | Mux |P L| | | | MSTI| | | 407 |header| PPP |F X|Len1 | PPP |Context| | UDP |RTP | 408 | (20) | Proto |F T| | Proto | ID | Link| Cksum |Data| 409 | | Field | | Field1| | Seq | | | 410 | | (1) |1-2 octets| (0-2) | (1-2) | (1) | (0-2) | | 411 +------+-------+----------+-------+-------+-----+-------+----+ 412 |<------------- IP payload ------------------------->| 413 |<----- PPPmux payload --------------------->| 415 If the tunnel contains multiplexed traffic, multiple "PPPMux 416 payload"s are transmitted in one IP packet. 418 3. Bandwidth Efficiency 420 The expected bandwidth efficiency attainable with TCRTP depends upon 421 a number of factors. These factors include multiplexing gain, 422 expected packet loss rate across the network, and rates of change of 423 specific fields within the IP and RTP headers. This section also 424 describes how TCRTP significantly enhances bandwidth efficiency for 425 voice over IP over ATM. 427 3.1. Multiplexing gains 428 Multiplexing reduces the overhead associated with the layer 2 and 429 tunnel headers. Increasing the number of CRTP payloads combined 430 into one multiplexed PPP payload increases multiplexing gain. As 431 traffic increases within a tunnel, more payloads are combined in one 432 multiplexed payload. This will increase multiplexing gain. 434 3.2. Packet loss rate 436 Loss of a multiplexed packet causes packet loss for all of the flows 437 within the multiplexed packet. 439 When the expected loss rate in a tunnel is relatively low (less than 440 perhaps 5%), the robust operation (described in [ECRTP]) should be 441 sufficient to ensure delivery of state changes. This robust 442 operation is characterized by a parameter N which means that the 443 probability of more than N adjacent packets getting lost on the 444 tunnel is small. 446 A value of N=1 will protect against the loss of a single packet 447 within a compressed session at the expense of bandwidth. A value of 448 N=2 will protect against the loss of two packets in a row within a 449 compressed session and so on. Higher values of N have higher 450 bandwidth penalties. 452 The optimal value of N will depend on the loss rate in the tunnel. 453 If the loss rate is high (above perhaps 5%) more advanced techniques 454 must be employed. Those techniques are beyond the scope of this 455 document. 457 3.3. Bandwidth calculation for Voice and Video Applications 459 The following formula uses the factors described above to model per- 460 flow bandwidth usage for both voice and video applications. These 461 variables are defined: 463 SOV-TCRTP, unit: octet. Per-payload overhead of ECRTP and the 464 multiplexed PPP header. This value does not include 465 additional overhead for updating IP ID or the RTP Time Stamp 466 fields (see [ECRTP] for details on IP ID). The value assumes 467 the use of the COMPRESSED_RTP payload type. It consists of 1 468 octet for the ECRTP context ID, 1 octet for COMPRESSED_RTP 469 flags, 2 octets for the UDP checksum, 1 octet for PPP 470 protocol ID, and 1 octet for the multiplexed PPP length 471 field. The total is 6 octets. 473 POV-TCRTP, unit: octet. Per-packet overhead of tunneled ECRTP. 474 This is the overhead for the tunnel header and the 475 multiplexed PPP payload type. This value is 20 octets for 476 the IP header, 4 octets for the L2TPv3 header and 1 octet for 477 the multiplexed PPP protocol ID. The total is 25 octets. 479 TRANSMIT-LENGTH, unit: milliseconds. The average duration of a 480 transmission (such as a talk spurt for voice streams). 482 SOV-TSTAMP, unit: octet. Additional per-payload overhead of the 483 COMPRESSED_UDP header that includes the absolute time stamp 484 field. This value includes 1 octet for the extra flags field 485 in the COMPRESSED_UDP header and 4 octets for the absolute 486 time stamp for a total of 5 octets. 488 SOV-IPID, unit: octet. Additional per-payload overhead of the 489 COMPRESSED_UDP header that includes the absolute IPID field. 490 This value includes 2 octets for the absolute IPID. This 491 value also includes 1 octet for the extra flags field in the 492 COMPRESSED_UDP header. The total is 3 octets. 494 IPID-RATIO, unit: integer values 0 or 1. Indicates the frequency at 495 which IPID will be updated by the compressor. If IPID is 496 changing randomly and thus always needs to be updated, then 497 the value is 1. If IPID is changing by a fixed constant 498 amount between payloads of a flow, then IPID-RATIO will be 0. 499 The value of this variable does not consider the IPID value 500 at the beginning of a voice or video transmission, as that is 501 considered by the variable TRANSMIT-LENGTH. The 502 implementation of the sending IP stack and RTP application 503 controls this behavior. See section 1.1. 505 NREP, unit: integer (usually a number between 1 and 3). This is the 506 number of times an update field will be repeated in ECRTP 507 headers to increase the delivery rate between the compressor 508 and decompressor. For this example, we will assume NREP=2. 510 PAYLOAD-SIZE, unit: octets. The size of the RTP payload in octets. 512 MUX-SIZE, unit: count. The number of PPP payloads multiplexed into 513 one multiplexed PPP payload. 515 SAMPLE-PERIOD, unit: milliseconds. The average delay between 516 transmissions of voice or video payloads for each flow in the 517 multiplex. For example, in voice applications the value of 518 this variable would be 10ms if all calls have a 10ms sample 519 period. 521 The formula is: 523 SOV-TOTAL = SOV-TCRTP + SOV-TSTAMP * (NREP * SAMPLE-PERIOD / 524 TRANSMIT-LENGTH) + SOV-IPID * IPID-RATIO 526 BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) * 527 8) / SAMPLE-PERIOD) 529 The results are: 531 BANDWIDTH, unit: kilobits per second. The average amount of 532 bandwidth used per voice or video flow. 534 SOV-TOTAL = The total amount of per-payload overhead associated with 535 tunneled ECRTP. It includes the per-payload overhead of 536 ECRTP and PPP, timestamp update overhead, and IPID update 537 overhead. 539 3.3.1. Voice Bandwidth Calculation Example 541 To create an example for a voice application using the above 542 formulas, we will assume the following usage scenario. Compressed 543 voice streams using G.729 compression with a 20 millisecond 544 packetization period. In this scenario, VAD is enabled and the 545 average talk spurt length is 1500 milliseconds. The IPID field is 546 changing randomly between payloads of streams. There is enough 547 traffic in the tunnel to allow 3 multiplexed payloads. The 548 following values apply: 550 SAMPLE-PERIOD = 20 milliseconds 551 TRANSMIT-LENGTH = 1500 milliseconds 552 IPID-RATIO = 1 553 PAYLOAD-SIZE = 20 octets 554 MUX-SIZE = 3 556 For this example, per call bandwidth is 16.4 kbits/sec. Classical 557 CRTP over a single HDLC link using the same factors as above yields 558 12.4 kbits/sec. 560 The effect of IPID can have a large effect on per call bandwidth. 561 If the above example is recalculated using an IPID-RATIO of 0, then 562 the per call bandwidth is reduced to 13.8 kbits/sec. Classical CRTP 563 over a single HDLC link using these same factors yields 11.2 564 kbits/call. 566 3.3.2. Voice Bandwidth Comparison Table 568 Using 5 simultaneous calls, no voice activity detection (VAD), G.729 569 with 20ms packetization interval, not considering RTCP overhead: 571 Normal VoIP over PPP: 124kbps 572 with classical CRTP on a link: 50kbps (savings: 59%) 573 with TCRTP over PPP: 62kbps (savings: 50%) 574 with TCRTP over AAL5: 85kbps (savings: 31%) 576 3.3.3. Video Bandwidth Calculation Example 578 Since TCRTP can be used to save bandwidth on any type of RTP 579 encapsulated flow, it can be used to save bandwidth for video 580 applications. This section documents an example of TCRTP based 581 bandwidth savings for MPEG-2 encoded video. 583 To create an example for a video application using the above 584 formulas, we will assume the following usage scenario. RTP 585 encapsulation of MPEG System and Transport Streams is performed as 586 described in RFC 2250. Frames for MPEG-2 encoded video are sent 587 continuously, so the TRANSMIT-LENGTH variable in the bandwidth 588 formula is essentially infinite. The IPID field is changing 589 randomly between payloads of streams. There is enough traffic in 590 the tunnel to allow 3 multiplexed payloads. The following values 591 apply: 593 SAMPLE-PERIOD = 2.8 milliseconds 594 TRANSMIT-LENGTH = infinite 595 IPID-RATIO = 1 596 PAYLOAD-SIZE = 1316 octets 597 MUX-SIZE = 3 599 For this example, per flow bandwidth is 3.8 Mbits/sec. MPEG video 600 with no header compression using the same factors as above yields 601 3.9 Mbits/sec. While TCRTP does provide some bandwidth savings for 602 video, the ratio of transmission headers to payload is so small that 603 the bandwidth savings are insignificant. 605 3.3.4. TCRTP over ATM 607 IP transport over AAL5 causes a quantizing effect to bandwidth 608 utilization due to the packets always being multiples of ATM cells. 610 For example, the payload size for G.729 using 10 millisecond 611 packetization interval is 10 octets. This is much smaller than the 612 payload size of an ATM cell (48 octets). When classical CRTP [CRTP] 613 is used on a link-by-link basis, the IP overhead to payload ratio is 614 quite good. However, AAL5 encapsulation and its cell padding always 615 force the minimum payload size to be one ATM cell, which results in 616 poor bandwidth utilization. 618 Instead of wasting this padding, the multiplexing of TCRTP allows 619 this previously wasted space in the ATM cell to contain useful data. 620 This is one of the main reasons why multiplexing has such a large 621 effect on bandwidth utilization with Voice over IP over ATM. 623 This multiplexing efficiency of TCRTP is similar to AAL2 sub-cell 624 multiplexing described in [I.363.1]. Unlike AAL2 sub-cell 625 multiplexing, however, TCRTP's multiplexing efficiency isn't limited 626 to only ATM networks. 628 3.3.5. TCRTP over non-ATM networks 630 When TCRTP is used with other layer 2 encapsulations that do not 631 have a minimum PDU size, the benefit of multiplexing is not as 632 great. 634 Depending upon the exact overhead of the layer 2 encapsulation, the 635 benefit of multiplexing might be slightly better or worse than link- 636 by-link CRTP header compression. The per-payload overhead of CRTP 637 tunneling is either 4 or 6 octets. If classical CRTP plus layer 2 638 overhead is greater than this amount, TCRTP multiplexing will 639 consume less bandwidth than classical CRTP when the outer IP header 640 is amortized over a large number of payloads. 642 The payload breakeven point can be determined by the following 643 formula: 645 POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX + SOV-PPPMUX 646 * MUX-SIZE 648 Where: 650 POV-L2, unit: octet. Layer 2 packet overhead: 5 octets for HDLC 651 encapsulation 653 POV-TUNNEL, unit: octet. Packet overhead due to tunneling: 24 654 octets IP header and L2TPv3 header 656 POV-PPPMUX, unit: octet. Packet overhead for the multiplexed PPP 657 protocol ID: 1 octet 659 SOV-PPPMUX, unit: octet. Per-payload overhead of PPPMUX, which is 660 comprised of the payload length field and the ECRTP protocol 661 ID. The value of SOV-PPPMUX is typically 1, 2, or 3. 663 If using HDLC as the layer 2 protocol, the breakeven point using the 664 above formula is when MUX-SIZE = 7. Thus 7 voice or video flows 665 need to be multiplexed to make TCRTP as bandwidth-efficient as lijnk 666 by link CRTP ocmpression. 668 4. Example implementation of TCRTP 669 This section describes an example implementation of TCRTP. 670 Implementations of TCRTP may be done in many ways as long as the 671 requirements of the associated RFCs are met. 673 Here is the path an RTP packet takes in this implementation: 675 +-------------------------------+ ^ 676 | Application | | 677 +-------------------------------+ | 678 | RTP | | 679 +-------------------------------+ Application and 680 | UDP | IP stack 681 +-------------------------------+ | 682 | IP | | 683 +-------------------------------+ V 684 | 685 | IP forwarding 686 | 687 +-------------------------------+ ^ 688 | ECRTP | | 689 +-------------------------------+ | 690 | PPPMUX | | 691 +-------------------------------+ Tunnel 692 | PPP | Interface 693 +-------------------------------+ | 694 | L2TP | | 695 +-------------------------------+ | 696 | IP | | 697 +-------------------------------+ V 698 | 699 | IP forwarding 700 | 701 +-------------------------------+ ^ 702 | Layer 2 | | 703 +-------------------------------+ Physical 704 | Physical | Interface 705 +-------------------------------+ V 707 A protocol stack is configured to create an L2TP tunnel interface to 708 a destination host. The tunnel is configured to negotiate the PPP 709 connection (using NCP IPCP) with ECRTP header compression and 710 PPPMUX. IP forwarding is configured to route RTP packets to this 711 tunnel. The destination UDP port number could distinguish RTP 712 packets from non- RTP packets. 714 The transmitting application gathers the RTP data from one source, 715 and formats an RTP packet. Lower level application layers add UDP 716 and IP headers to form a complete IP packet. 718 The RTP packets are routed to the tunnel interface where headers are 719 compressed, payloads multiplexed, and then tunneled to the 720 destination host. 722 The operation of the receiving node is the same as the transmitting 723 node in reverse. 725 4.1. Suggested PPP and L2TP negotiation for TCRTP 727 This section describes the necessary PPP and LT2P negotiations 728 necessary for establishing a PPP connection and L2TP tunnel with 729 L2TP header compression. The negotiation is between two peers: 730 Peer1 and Peer2. 732 4.2. PPP negotiation TCRTP 734 The Point-to-Point Protocol is described in [PPP]. 736 4.2.1. LCP negotiation 738 Link Control Processing (LCP) is described in [PPP]. 740 4.2.1.1. Link Establishment 742 Peer1 Peer2 743 ----- ----- 744 Configure-Request (no options) -> 745 <- Configure-Ack 746 <- Configure-Request (no options) 747 Configure-Ack -> 749 4.2.1.2. Link Tear Down 751 Terminate-Request -> 752 <- Terminate-Ack 754 4.2.2. IPCP negotiation 756 The protocol exchange here is described in [IPHCOMP], [PPP], and 757 [ECRTP]. 759 Peer1 Peer2 760 ----- ----- 761 Configure-Request -> 762 Options: 763 IP-Compression-Protocol 764 Use protocol 0x61 765 and sub-parameters 766 as described in 768 [IPCP-HC] and [ECRTP] 769 <- Configure-Ack 770 <- Configure-Request 771 Options: 772 IP-Compression-Protocol 773 Use protocol 0x61 774 and sub-parameters 775 as described in 776 [IPCP-HC] and [ECRTP] 777 Configure-Ack -> 779 4.3. L2TP negotiation 781 L2TP is described in [L2TPv3]. 783 4.3.1. Tunnel Establishment 785 Peer1 Peer2 786 ----- ----- 787 SCCRQ -> 788 Mandatory AVP's: 789 Message Type 790 Protocol Version 791 Host Name 792 Framing Capabilities 793 Assigned Tunnel ID 794 <- SCCRP 795 Mandatory AVP's: 796 Message Type 797 Protocol Version 798 Host Name 799 Framing Capabilities 800 Assigned Tunnel ID 801 SCCCN -> 802 Mandatory AVP's: 803 Message Type 804 <- ZLB 806 4.3.2. Session Establishment 808 Peer1 Peer2 809 ----- ----- 810 ICRQ -> 811 Mandatory AVP's: 812 Message Type 813 Assigned Session ID 814 Call Serial Number 815 <- ICRP 816 Mandatory AVP's: 818 Message Type 819 Assigned Session ID 820 ICCN -> 821 Mandatory AVP's: 822 Message Type 823 Tx (Connect Speed) 824 Framing Type 825 <- ZLB 827 4.3.3. Tunnel Tear Down 829 Peer1 Peer2 830 ----- ----- 831 StopCCN -> 832 Mandatory AVP's: 833 Message Type 834 Assigned Tunnel ID 835 Result Code 836 <- ZLB 838 5. IANA Considerations 840 This document does not require any assignments from IANA. 842 6. Security Considerations 844 This document describes a method for combining several existing 845 protocols implementing compression, multiplexing, and tunneling of 846 RTP streams. Attacks on the component technologies of TCRTP include 847 attacks on RTP/RTCP headers and payloads carried within a TCRTP 848 session, attacks on the compressed headers, attacks on the 849 multiplexing layer, or attacks on the tunneling negotiation or 850 transport. The security issues associated individually with each of 851 those component technologies are addressed in their respective 852 specifications, [ECRTP], [PPP-MUX], [L2TPv3], along with the 853 security considerations for RTP itself [RTP]. 855 However, there may be additional security considerations arising 856 from the use of these component technologies together. For example, 857 there may be an increased risk of unintended misdelivery of packets 858 from one stream in the multiplex to another due to a protocol 859 malfunction or data error because the addressing information is more 860 condensed. This is particularly true if the tunnel is transmitted 861 over a link-layer protocol that allows delivery of packets 862 containing bit errors in combination with a tunnel transport layer 863 option that does not checksum all of the payload. 865 The opportunity for malicious misdirection may be increased relative 866 to that for a single RTP stream transported by itself because 867 addressing information must be unencrypted for the header 868 compression and multiplexing layers to function. 870 The primary defense against misdelivery is to make the data unusable 871 to unintended recipients through cryptographic techniques. The 872 basic method for encryption provided in the RTP specification [RTP] 873 is not suitable because it encrypts the RTP and RTCP headers along 874 with the payload. However, the RTP specification also allows 875 alternative approaches to be defined in separate profile or payload 876 format specifications wherein only the payload portion of the packet 877 would be encrypted so header compression may be applied to the 878 encrypted packets. One such profile [SRTP] provides more 879 sophisticated and complete methods for encryption and message 880 authentication than the basic approach in [RTP]. Additional methods 881 may be developed in the future. Appropriate cryptographic 882 protection should be incorporated into all TCRTP applications. 884 7. Acknowledgements 886 The authors would like to thank the authors of RFC2508, Stephen 887 Casner and Van Jacobson, and the authors of RFC2507, Mikael 888 Degermark, Bjorn Nordgren, and Stephen Pink. 890 The authors would also like to thank Dana Blair, Alex Tweedley, 891 Paddy Ruddy, Francois Le Faucheur, Tim Gleeson, Matt Madison, 892 Hussein Salama, Mallik Tatipamula, Mike Thomas, Mark Townsley, 893 Andrew Valencia, Herb Wildfeuer, J. Martin Borden, John 894 Geevarghese, and Shoou Yiu. 896 8. References 898 Normative References 900 [PPP-MUX] R. Pazhyannur, I. Ali, C. Fox, "PPP Multiplexing", 901 RFC3153, August 2001. 903 [ECRTP] T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. 904 Ruddy, " Enhanced Compressed RTP (CRTP) for Links with High 905 Delay, Packet Loss and Reordering",RFC3545, July 2003. 907 [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 908 Low-Speed Serial Links", RFC2508, February 1999. 910 [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, "IP Header 911 Compression", RFC2507, February 1999. 913 [IPCP-HC] M. Engan, S. Casner, C. Bormann, "IP Header Compression 914 over PPP", RFC2509, February 1999. 916 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: 917 A Transport Protocol for Real-Time Applications", RFC1889, 918 January 1996. 920 [L2TP] M. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. 921 Palter, "Layer Two Tunneling Protocol "L2TP"", RFC2661, 922 August 1999. 924 [L2TPv3] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 925 Protocol (Version 3)", draft-ietf-l2tpext-l2tp-base-14.txt, 926 June 2004. 928 [I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 929 2 AAL", I.363.2, September 1997. 931 [EF-PHB] V. Jacobson, K. Nichols, K. Poduri, "An Expedited 932 Forwarding PHB", RFC2598, June 1999. 934 [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC1661, 935 July 1994. 937 Informative References 939 [SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, 940 "The Secure Real-time Transport Protocol (SRTP)",RFC3711, 941 March 2004. 943 [REORDER] G. Pelletier, L. Jonsson, K. Sandlund, "RObust Header 944 Compression (ROHC): ROHC over Channels that can Reorder 945 Packets", Work in Progress, , June 2004. 948 [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 949 Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., 950 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, 951 T., Yoshimura, T. and H. Zheng, "RObust Header Compression 952 (ROHC): Framework and four profiles: RTP, UDP, ESP, and 953 uncompressed", RFC 3095, July 2001. 955 9. Authors' Addresses 957 Bruce Thompson 958 170 West Tasman Drive 959 San Jose, CA 95134-1706 960 United States of America 961 Phone: +1 408 527 0446 962 Email: brucet@cisco.com 964 Tmima Koren 965 170 West Tasman Drive 966 San Jose, CA 95134-1706 967 United States of America 969 Phone: +1 408 527 6169 970 Email: tmima@cisco.com 972 Dan Wing 973 170 West Tasman Drive 974 San Jose, CA 95134-1706 975 United States of America 977 Email: dwing@cisco.com 979 10. Copyright Notice 981 Copyright (C) The Internet Society (2004). This document is subject 982 to the rights, licenses and restrictions contained in BCP 78, and 983 except as set forth therein, the authors retain all their rights. 985 11. Disclaimers 987 This document and the information contained herein are provided 988 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 989 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 990 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 991 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 992 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 993 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 995 The IETF takes no position regarding the validity or scope of any 996 Intellectual Property Rights or other rights that might be claimed 997 to pertain to the implementation or use of the technology described 998 in this document or the extent to which any license under such 999 rights might or might not be available; nor does it represent that 1000 it has made any independent effort to identify any such rights. 1001 Information on the procedures with respect to rights in RFC 1002 documents can be found in BCP 78 and BCP 79. 1004 Copies of IPR disclosures made to the IETF Secretariat and any 1005 assurances of licenses to be made available, or the result of an 1006 attempt made to obtain a general license or permission for the use 1007 of such proprietary rights by implementers or users of this 1008 specification can be obtained from the IETF on-line IPR repository 1009 at http://www.ietf.org/ipr. 1011 The IETF invites any interested party to bring to its attention any 1012 copyrights, patents or patent applications, or other proprietary 1013 rights that may cover technology that may be required to implement 1014 this standard. Please address the information to the IETF at ietf- 1015 ipr@ietf.org.