idnits 2.17.1 draft-ietf-avt-tcrtp-00.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 400 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 116 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'L2TPHC' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'PPPMUX' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'ECRTP' is defined on line 299, but no explicit reference was found in the text == Unused Reference: 'CRTP' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'IPHCOMP' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'IPCPHC' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RTP' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'L2TP' is defined on line 315, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-l2tpext-l2tphc-00 -- Possible downref: Normative reference to a draft: ref. 'L2TPHC' == Outdated reference: A later version (-03) exists of draft-ietf-pppext-pppmux-00 -- Possible downref: Normative reference to a draft: ref. 'ECRTP' ** Obsolete normative reference: RFC 2509 (ref. 'IPCPHC') (Obsoleted by RFC 3544) ** Obsolete normative reference: RFC 1889 (ref. 'RTP') (Obsoleted by RFC 3550) Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 4 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 March 3, 2000 Tmima Koren 3 Expires October 2000 Dan Wing 4 draft-ietf-avt-tcrtp-00.txt Cisco Systems 6 Tunneling multiplexed Compressed RTP ("TCRTP") 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsolete by other documents 18 at any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society (2000). All Rights Reserved. 31 1. Abstract 33 This document describes a method to improve the end-to-end bandwidth utilization 34 of RTP streams over an IP network using compression and multiplexing. Several 35 application level compression/multiplexing solutions have been evaluated so far 36 in the IETF AVT Working Group. This proposal differs from other solutions in 37 that neither compression nor multiplexing needs to be done at application level. 38 Because of this, existing RTP based applications do not need to change to 39 support this encapsulation format. 41 Instead of proposing a new encapsulation format for end to end multiplexing, 42 this document describes the application of existing protocols for compression, 43 multiplexing, and end to end tunneling. 45 2. Introduction 47 This document describes the application of existing protocols for compression, 48 multiplexing, and end to end tunneling that can be used by RTP applications to 49 implement an end to end multiplexing scheme for RTP transport. Header 50 Compression is used to reduce the header overhead of a single RTP payload. 51 Tunneling is used to transport compressed headers and payloads through a 52 multiple hop IP network without having to compress and decompress at each link. 53 Multiplexing is used to reduce the overhead of tunnel headers by amortizing a 54 single tunnel header over many RTP payloads. 56 For compression, this document proposes the use of RFC 2508 based RTP header 57 compression (CRTP). RFC 2508 describes the use of RTP header compression on an 58 unspecified link layer transport. Most CRTP implementations use PPP as the link 59 layer transport for the session. PPP has been integrated with a number of 60 physical link layer protocols such as HDLC. When PPP is integrated with a 61 physical link layer for CRTP transport, it has the disadvantage that headers 62 must be compressed and decompressed at each IP hop in an end to end network. 64 A CRTP session can be made to work across multiple IP hops to enable end to end 65 compression by tunneling the PPP session. The tunneling protocol proposed by 66 this document is L2TP (RFC 2661). L2TP is a general tunneling protocol for PPP 67 sessions. Since PPP is used as the link layer protocol for CRTP, the extensions 68 described in RFC 2509 are required to negotiate the CRTP session. 70 When the overhead of a tunnel header is added to a single compressed RTP 71 payload, there is very little bandwidth savings when compared to uncompressed 72 transport of RTP streams. Multiplexing is required to amortize the overhead of 73 the tunnel header over many RTP payloads. The multiplexing format that is 74 proposed by this document is PPP multiplexing (Draft-ietf-pppext-pppmux-00.txt). 75 PPP multiplexing allows many PPP payloads to be encapsulated as a single 76 multiplexed PPP payload. The resulting multiplexed PPP payload can then be 77 transported between two RTP endpoints using L2TP. 79 In order to make end to end transport of CRTP sessions efficient when using 80 L2TP, some extensions are needed to both the CRTP protocol and the L2TP 81 protocol. This document describes extensions that have been proposed for these 82 protocols to make them more efficient when they are used as described in this 83 document. These extensions to CRTP and L2TP have been proposed in separate 84 Internet drafts. 86 3. Protocol Operation and Recommended Extensions 88 3.1. CRTP 90 When CRTP sessions are transported through a network using an L2TP tunnel, some 91 of the basic assumptions used for CRTP over a single physical link may no longer 92 be valid. Tunneling a CRTP session through multiple IP hops may increase the 93 round trip delay and the chance of packet loss. CRTP contexts get invalidated 94 due to packet loss. The CRTP error recovery mechanism using CONTEXT_STATE 95 messages can compound the loss problem when long round trip delays are involved. 96 This is because once the CRTP decompressor context state gets out of sync with 97 the compressor, it will drop packets associated with the context until the two 98 states are resynchronized. Resynchronization involves the transmission of the 99 CONTEXT_STATE message from the decompressor to the compressor, and a FULL_HEADER 100 message from the compressor to the decompressor. 102 Enhancements to CRTP are needed to minimize feedback based error recovery using 103 context state messages. Draft-koren-avt-crtp-enhance-01.txt proposes CRTP 104 enhancements to make it more tolerant of packet loss, and minimize the need to 105 use the CRTP error recovery mechanism. Specific recommendations for the use of 106 the CRTP protocol when transported through a tunnel are described below. 108 The CU* packet format described in Draft-koren-avt-crtp-enhance-01.txt should be 109 used to synchronize CRTP compressor and decompressor state whenever the incoming 110 packet stream causes a change in the compressor context state. The CU* packet 111 format allows any portion of the context state to be transmitted from the 112 compressor to the decompressor. 114 To ensure delivery of state changes, CU* packets should be delivered using 115 either the N mode of operation or the ACK mode of operation described in Draft- 116 koren-avt-crtp-enhance-01.txt. The method that should be used depends on the 117 expected loss rate of packets in the network. Networks with a low loss rate for 118 packets in the tunnel should use the N mode of operation. Networks with a high 119 loss rate should use the ACK mode of operation. 121 UDP checksums should be used for RTP packets transported using TCRTP. The twice 122 algorithm described in RFC 2508 should be used by the CRTP decompressor to 123 resynchronize context state in the event of packet loss within the tunnel. In 124 the event that UDP checksums are not generated by the application, the CRTP 125 compressor should use the CRTP Headers checksum described in Draft-koren-avt- 126 crtp-enhance-01.txt. 128 Tunneled transport does not guarantee in order delivery of packets. Therefore, 129 the CRTP decompressor must be capable of operation in the presence of out of 130 order packet delivery. A CRTP decompressor may treat out of order delivery the 131 same as packet loss. There is no need to reorder packets that are delivered out 132 of order. 134 3.2 PPP Multiplexing 136 Draft-ietf-pppext-pppmux-00.txt describes an encapsulation that allows combining 137 multiple PPP payloads into one multiplexed payload. The encapsulation format 138 used for PPP multiplexing allows any supported PPP payload type to be 139 multiplexed. 141 3.3. L2TP 143 L2TP tunnels should be used to tunnel the CRTP payloads end to end. This is a 144 natural choice since CRTP payloads are PPP payloads, and L2TP allows tunneled 145 transport of PPP payloads. L2TP includes methods for tunneling messages used in 146 PPP session establishment such as NCP. This allows the procedures of RFC 2509 to 147 be used for negotiating the use of CRTP within a tunnel and to negotiate 148 compression/decompression parameters to be used for the CRTP session. 150 To get reasonable bandwidth efficiency using multiplexing within an L2TP tunnel, 151 multiple RTP streams must be active between the source and destination of an 152 L2TP tunnel. If the source and destination of the L2TP tunnel are the same as 153 the source and destination of the CRTP sessions, then the source and destination 154 must have multiple active RTP streams to get any benefit from multiplexing. 155 Because of this limitation, TCRTP is mostly useful for applications where many 156 RTP sessions run between a pair of RTP endpoints. The number of simultaneous RTP 157 sessions required to reduce the header overhead to a minimum depends on how big 158 the L2TP header is. A smaller L2TP header will result in fewer simultaneous RTP 159 sessions being required to produce bandwidth efficiencies similar to CRTP. 161 Draft-ietf-l2tpext-l2tphc-00.txt describes a method of compressing L2TP tunnel 162 headers from 36 bytes including the IP header to 21 bytes. L2TPHC packets 163 include an IP header, using an IP protocol that is negotiated between the two 164 hosts at the ends of the L2TP tunnel. The UDP header is omitted, and the L2TPHC 165 header is reduced to 1 byte. The added overhead is now 21 bytes of the combined 166 IP and L2TPHC headers. 168 When L2TP is used to carry CRTP streams, the RTP streams may use the EF DSCP. 169 When an EF packet is tunneled, the tunnel header must be marked as EF. This is a 170 requirement of RFC 2598. To prevent TCRTP tunnels from using excess EF 171 bandwidth, it is recommended that only packets marked with the EF DSCP be 172 transported in the tunnel. 174 3.4 Encapsulation Formats 176 The packet format for an RTP packet compressed with RTP header compression 177 As defined in RFC 2508 is: 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | + MSTI + + | 181 | Context + + UDP + | 182 | ID + Link + Checksum + RTP Data | 183 | + Sequence+ + | 184 | (1-2) + (1) + (0,2) + | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 The packet format of a multiplexed PPP packet is as follows: 188 (diagram taken from draft-ietf-pppext-pppmux-00.txt) 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Mux +P| + + + +P| + + + 192 | PPP +F| Len1 + PPP + + +F| LenN + PPP + + 193 | Prot. +F| + Prot. +Info1+ ~ +F| + Prot. +InfoN+ 194 | Field + |(7bits)+ Field1+ + + |(7bits)+FieldN + + 195 | (2) +(1 byte )+ (0-2) + + +(1 byte) + (0-2) + + 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ 198 The format of an L2TPHC packet with a PPP payload is: 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | IP header | L2TPHC | PPP payload | 202 | | Header | | 203 | (20) | (1) | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 The combined format used for TCRTP with a single payload is: 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | IP hdr | L2TPHC| Mux +P| + + + MSTI + + | 210 | | Header| PPP +F| Len1 + PPP + Context + + UDP + RTP | 211 | (20) | (1) | Prot. +F| + Prot. + ID + Link + Cksum + Data | 212 | | | Field + |(7bits)+ Field1+ + Seq + + | 213 | | | (2) +(1 byte )+ (0-2) + (1-2) + (1) + (1-2) + | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 CRTP is defined in RFC2508 218 Extensions to CRTP to make it more tolerant to packet loss are defined in: 219 draft-koren-avt-crtp-enhance-01.txt. 221 L2TPHC is defined in: draft-ietf-l2tpext-l2tphc-00.txt 223 PPP multiplexing is defined in: draft-ietf-pppext-pppmux-00.txt 225 4. Example implementation of TCRTP 227 This section describes an example implementation of TCRTP. Implementations of 228 TCRTP may be done in many ways as long as the requirements of the associated 229 RFCs are met. 231 Here is the path an RTP packet takes in this implementation: 233 +---+---+---+---+---+---+---+---+ + 234 | Application | | 235 +---+---+---+---+---+---+---+---+ | 236 | RTP | | 237 +---+---+---+---+---+---+---+---+ Application 238 | UDP | | 239 +---+---+---+---+---+---+---+---+ | 240 | IP | | 241 +---+---+---+---+---+---+---+---+ + 242 | 243 | 244 | IP forwarding 245 | 246 + 247 +---+---+---+---+---+---+---+---+ + 248 | CRTP | | 249 +---+---+---+---+---+---+---+---+ | 250 | PPPMUX | | 251 +---+---+---+---+---+---+---+---+ Tunnel 252 | PPP | Interface 253 +---+---+---+---+---+---+---+---+ | 254 | L2TP | | 255 +---+---+---+---+---+---+---+---+ | 256 | Layer 2 | | 257 +---+---+---+---+---+---+---+---+ + 259 A protocol stack is configured to create an L2TP tunnel interface to a 260 destination host. The tunnel is configured to negotiate NCP IPCP with CRTP 261 header compression and PPPMUX. IP forwarding is configured to route packets with 262 the same destination address of the previously configured L2TP tunnel interface 263 to that tunnel interface. To ensure that other traffic destined to the same IP 264 address is not routed to this tunnel interface, the forwarding module should be 265 configured to examine additional information in the IP packet. The destination 266 UDP port number is an example of the additional information that may be used to 267 select the L2TP tunnel interface. 269 The transmitting application gathers the RTP data and formats an RTP packet. 270 Lower level application layers add UDP and IP headers to form a complete IP 271 packet. 273 The RTP packets are routed to the tunnel interface where they are compressed, 274 multiplexed, and tunneled to the destination host. 276 The operation of the receiving node is the same as the transmitting node in 277 reverse. 279 3. Acknowledgements 281 The authors would like to thank the authors of RFC2508, Stephen Casner 282 and Van Jacobson, and the authors of RFC2507, Mikael Degermark, Bjorn 283 Nordgren, and Stephen Pink. 285 The authors would also like to thank Dana Blair, Alex Tweedley, 286 Paddy Ruddy, Francois Le Faucheur, Tim Gleeson, Matt Madison, 287 Hussein Salama, Mallik Tatipamula, Mike Thomas, Mark Townsley, 288 Andrew Valencia, Herb Wildfeuer, J Martin Borden, John Geevarghese, 289 and Shoou Yiu. 291 4. References 293 [L2TPHC] A. Valencia, "L2TP Header Compression (`L2TPHC')", 294 draft-ietf-l2tpext-l2tphc-00.txt, January 2000. 296 [PPPMUX] R. Pazhyannur, I. Ali, "PPP Multiplexed Frame Option", 297 draft-ietf-pppext-pppmux-00.txt, January 2000. 299 [ECRTP] T. Koren, S. Casner, P. Ruddy, B. Thompson, A. Tweeedly, D. Wing, 300 J. Geevarghese, "Enhancements to IP/UDP/RTP Header Compression", 301 draft-koren-avt-crtp-enhance-01.txt, March 2000. 303 [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 304 Low-Speed Serial Links", RFC2508, February 1999. 306 [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression", 307 RFC2507, February 1999. 309 [IPCPHC] M. Engan, S. Casner, C. Bormann, 310 "IP Header Compression over PPP", RFC2509, February 1999. 312 [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A 313 Transport Protocol for Real-Time Applications", RFC1889, January 1996. 315 [L2TP] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, 316 "Layer Two Tunneling Protocol "L2TP"", RFC2661, August 1999. 318 5. Authors' Addresses 320 Bruce Thompson 321 170 West Tasman Drive 322 San Jose, CA 95134-1706 323 United States of America 325 Phone: +1 408 527 0446 326 Email: brucet@cisco.com 328 Tmima Koren 329 170 West Tasman Drive 330 San Jose, CA 95134-1706 331 United States of America 333 Phone: +1 408 527 6169 334 Email: tmima@cisco.com 336 Dan Wing 337 170 West Tasman Drive 338 San Jose, CA 95134-1706 339 United States of America 341 Phone: +1 408 525 5314 342 Email: dwing@cisco.com 344 6. Full Copyright Statement 346 Copyright (C) The Internet Society (2000). All Rights Reserved. 348 This document and translations of it may be copied and furnished to 349 others, and derivative works that comment on or otherwise explain it 350 or assist in its implementation may be prepared, copied, published 351 and distributed, in whole or in part, without restriction of any 352 kind, provided that the above copyright notice and this paragraph are 353 included on all such copies and derivative works. However, this 354 document itself may not be modified in any way, such as by removing 355 the copyright notice or references to the Internet Society or other 356 Internet organizations, except as needed for the purpose of 357 developing Internet standards in which case the procedures for 358 copyrights defined in the Internet Standards process must be 359 followed, or as required to translate it into languages other than 360 English. 362 The limited permissions granted above are perpetual and will not be 363 revoked by the Internet Society or its successors or assigns. 365 This document and the information contained herein is provided on an 366 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 367 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 368 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 369 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 370 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.