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