idnits 2.17.1 draft-saldana-tsvwg-tcmtf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4170, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 587 has weird spacing: '...et Loss and R...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 16, 2012) is 4454 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FLV' -- Possible downref: Non-RFC (?) normative reference: ref. 'GRE' ** Obsolete normative reference: RFC 4995 (ref. 'ROHC') (Obsoleted by RFC 5795) ** Obsolete normative reference: RFC 4960 (ref. 'SCTP') (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group J. Saldana, Ed. 3 Internet-Draft University of Zaragoza 4 Obsoletes: 4170 (if approved) February 16, 2012 5 Intended status: BCP 6 Expires: August 19, 2012 8 Tunneling Compressed Multiplexed Traffic Flows (TCMTF) 9 draft-saldana-tsvwg-tcmtf-00 11 Abstract 13 This document describes a method to improve the bandwidth utilization 14 of network paths that carry multiple streams in parallel between two 15 endpoints, as in voice trunking. The method combines standard 16 protocols that provide compression, multiplexing, and tunneling over 17 a network path for the purpose of reducing the bandwidth used when 18 multiple streams are carried over that path. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 19, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Bandwidth efficiency of real-time flows . . . . . . . . . 3 57 1.3. Real-time applications not using RTP . . . . . . . . . . . 4 58 1.4. Scenarios of application . . . . . . . . . . . . . . . . . 5 59 1.5. Objective of this standard . . . . . . . . . . . . . . . . 5 60 1.6. Overview of Protocols . . . . . . . . . . . . . . . . . . 6 61 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8 62 2.1. Models of implementation . . . . . . . . . . . . . . . . . 8 63 2.2. Choice of the compressing protocol . . . . . . . . . . . . 9 64 2.2.1. Context Synchronization in ECRTP . . . . . . . . . . . 10 65 2.2.2. Context Synchronization in ROHC . . . . . . . . . . . 10 66 2.3. Multiplexing . . . . . . . . . . . . . . . . . . . . . . . 10 67 2.3.1. Tunneling Inefficiencies . . . . . . . . . . . . . . . 11 68 2.4. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 11 69 2.5. Encapsulation Formats . . . . . . . . . . . . . . . . . . 11 70 3. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 This document describes a way to combine existing protocols for 82 compression, multiplexing, and tunneling to save bandwidth for some 83 applications that generate small packets, such as real-time ones. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 1.2. Bandwidth efficiency of real-time flows 93 In the last years we are witnessing the raise of new real-time 94 services that use the Internet for the delivery of interactive 95 multimedia applications. The most common of these services is VoIP, 96 but many others have been developed, and are experiencing a 97 significant growth: videoconferencing, telemedicine, video vigilance, 98 online gaming, etc. 100 The first design of the Internet did not include any mechanism 101 capable of guaranteeing an upper bound for delivery delay, taking 102 into account that the first deployed services were e-mail, file 103 transfer, etc., in which delay is not critical. RTP [RTP] was first 104 defined in 1996 in order to permit the delivery of real-time 105 contents. Nowadays, although there are a variety of protocols used 106 for signaling real-time flows (SIP [SIP], H.323, etc.), RTP has 107 become the standard par excellence for the delivery of real-time 108 content. 110 RTP was designed to work over UDP datagrams. This implies that an 111 IPv4 packet carrying real-time information has to include 40 bytes of 112 headers: 20 for IPv4 header, 8 for UDP, and 12 for RTP. This 113 overhead is significant, taking into account that many real-time 114 services send very small payloads. It becomes even more significant 115 with IPv6 packets, as the basic IPv6 header is twice the size of the 116 IPv4 header (Table 1). 118 +---------------------------------+---------------------------------+ 119 | IPv4 | IPv6 | 120 +---------------------------------+---------------------------------+ 121 | IPv4+UDP+RTP: 40 bytes header | IPv6+UDP+RTP: 60 bytes header | 122 | G.711 at 20 ms packetization: | G.711 at 20 ms packetization: | 123 | 25% header overhead | 37.5% header overhead | 124 | G.729 at 20 ms packetization: | G.729 at 20 ms packetization: | 125 | 200% header overhead | 300% header overhead | 126 +---------------------------------+---------------------------------+ 128 Table 1: Efficiency of different voice codecs 130 In order to mitigate this bad network efficiency, the multiplexing of 131 a number of payloads into a single packet can be considered as a 132 solution. If we have only one flow, the number of samples included 133 in a packet can be increased, but at the cost of adding new 134 packetization delays. However, if a number of flows share the same 135 path between an origin and a destination, a multiplexer can build a 136 bigger packet in which a number of payloads share a common header. A 137 demultiplexer is necessary at the end of the common path, so as to 138 rebuild the packets as they were originally sent, making multiplexing 139 a transparent process for the extremes of the flow. 141 The headers of the original packets can be compressed to save more 142 bandwidth, taking into account that there exist some header 143 compressing standards ([cRTP], [ECRTP], [IPHC], [ROHC]). When 144 different headers are compressed together, tunneling can be used to 145 relieve intermediate routers from the decompression and compression 146 processing. 148 1.3. Real-time applications not using RTP 150 But there are many real-time applications that do not use RTP. Some 151 of them send UDP packets, e.g. First Person Shooter (FPS) online 152 games, for which latency is very critical. There is also another 153 fact which has to be taken into account: TCP is getting used for 154 media delivery. For many reasons, such as avoiding firewalls, the 155 standard RTP/UDP/IP protocol stack is substituted in many cases by 156 FLV/HTTP/TCP/IP (FLash Video [FLV]). 158 There is also another kind of applications which have been reported 159 as real-time using TCP: MMORPGs (Massively Multiplayer Online Role 160 Playing Games), which in some cases have millions of players, 161 thousands of them sharing the same virtual world. They use TCP 162 packets to send the player commands to the server, and also to send 163 to the player's application the characteristics and situation of 164 other gamers' avatars. These games do not have the same 165 interactivity of FPSs, but the quickness and the movements of the 166 player are important, and can decide if they win or lose a fight. 168 1.4. Scenarios of application 170 Different scenarios of application can be considered for the 171 tunneling, compressing and multiplexing solution: for example, voice 172 trunking between gateways of different offices of an enterprise. 173 Also, the traffic of the users of an application in a town or a 174 district, which can be multiplexed and sent to the central server. 175 Also Internet cafes are suitable of having many users of the same 176 application (e.g. a game) sharing the same access link. 178 Another interesting scenario are satellite communication links that 179 often manage the bandwidth by limiting the transmission rate, 180 measured in packets per second (pps), to and from the satellite. 181 Applications like VoIP that generate a large number of small packets 182 can easily fill the limited number of pps slots, limiting the 183 throughput across such links. As an example, a G.729a voice call 184 generates 50 pps at 20 ms packetization time. If the satellite 185 transmission allows 1,500 pps, the number of simultaneous voice calls 186 is limited to 30. This results in poor utilization of the satellite 187 link's bandwidth as well as places a low bound on the number of voice 188 calls that can utilize the link simultaneously. Multiplexing small 189 packets into one packet for transmission would improve the 190 efficiency. Satellite links would also find it useful to multiplex 191 small TCP packets into one packet. This could be especially 192 interesting for compressing TCP ACKs. 194 There is still another interesting use case: desktop or application 195 sharing where the traffic from the server to the client typically 196 consists of the delta of screen updates. Also, the standard for 197 remote desktop sharing emerging for WebRTC in the RTCWEB Working 198 Group is: {something}/SCTP/UDP (Stream Control Transmission Protocol 199 [SCTP]). In this scenario, SCTP/UDP could be used in other cases: 200 chatting, file sharing and applications related to WebRTC peers. 201 There could be hundreds of clients at a site talking to a server 202 located at a datacenter over a WAN. Compressing, multiplexing and 203 tunneling this traffic could save WAN bandwidth and potentially 204 improve latency. 206 1.5. Objective of this standard 208 In conclusion, a standard that multiplexes, compresses and sends 209 packets using a tunnel can be interesting for many enterprises: 210 developers of VoIP systems can include this option in their 211 solutions; or game providers, who can achieve bandwidth savings in 212 their supporting infrastructures. Other fact that has to be taken 213 into account is that the technique not only saves bandwidth but also 214 reduces the number of packets per second, which sometimes can be a 215 bottleneck for a satellite link or even for a network router. 217 If only one stream is tunneled and compressed, then little bandwidth 218 savings will be obtained. In contrast, multiplexing is helpful to 219 amortize the overhead of the tunnel header over many payloads. 221 1.6. Overview of Protocols 223 The current standard [TCRTP] defines a way to combine different 224 standard protocols. Three layers are considered, as shown in the 225 figure: 227 RTP/UDP 228 | 229 | ---------------------------- 230 | 231 ECRTP compressing layer 232 | 233 | ---------------------------- 234 | 235 PPPMUX multiplexing layer 236 | 237 | ---------------------------- 238 | 239 L2TP tunneling layer 240 | 241 | ---------------------------- 242 | 243 IP 245 Figure 1 247 In contrast, the new proposal includes other protocols to be 248 compressed in addition to RTP/UDP, since real-time services can also 249 be provided using UDP or TCP. 251 G.711 or other payload 252 | ------------------------------ 253 | 254 G.711.0 or other payload compression payload compression layer 255 | 256 | ------------------------------ 257 TCP UDP RTP/UDP 258 | | | 259 \ | / ------------------------------ 260 \ | / 261 Nothing or ROHC or ECRTP or IPHC header compressing layer 262 | 263 | ------------------------------ 264 | 265 PPPMUX or other mux protocols multiplexing layer 266 | 267 | ------------------------------ 268 | 269 GRE or L2TP or other tunneling layer 270 | 271 | ------------------------------ 272 IP 274 Figure 2 276 Each of the three layers is considered as independent of the other 277 two, i.e. different combinations of protocols can be implemented 278 according to the new standard: 280 o Regarding compression, a number of options can be considered: as 281 the standards are able to compress different headers, the one to 282 be used could be selected depending on the traffic to compress. 283 It also exists the possibility of having a null header 284 compression, in the case of wanting to avoid traffic compression, 285 taking into account the need of storing a context for every flow 286 and the problems of context desynchronization in certain 287 scenarios. For this, different header compression protocols have 288 been defined ([cRTP], [ECRTP], [IPHC], [ROHC]) by the IETF. 290 o Multiplexing is accomplished using PPP Multiplexing [PPP-MUX]. 291 Nevertheless, other multiplexing protocols can also be considered. 293 o Tunneling is accomplished by using L2TP (Layer 2 Tunneling 294 Protocol [L2TPv3]), GRE (Generic Routing Encapsulation [GRE]) or 295 other schemes. 297 Finally, another option has been considered: A payload compression 298 layer. When the payload is G.711 this layer can runs G.711.0, a 299 lossless and stateless compression/decompression of the payload 300 [I.711]. This operations can be deployed by network elements like 301 routers/switches, without the endpoints having to signal it using 302 RTSP/SDP/SIP, since G.711 has a fixed RTP payload number. 304 2. Protocol Operation 306 This section describes how to combine three protocols: compressing, 307 multiplexing, and tunneling, to save bandwidth for real-time 308 applications. 310 2.1. Models of implementation 312 TCMTF can be implemented in different ways. The most straightforward 313 is to implement it in the devices terminating the real-time streams 314 (these devices can be e.g. voice gateways, or proxies grouping a 315 number of flows): 317 [ending device]---[ending device] 318 ^ 319 | 320 TCMTF over IP 322 Figure 3 324 Another way TCMTF can be implemented is with an external 325 concentration device. This device could be placed at strategic 326 places in the network and could dynamically create and destroy TCMTF 327 sessions without the participation of the endpoints that generate 328 real-time flows. 330 [ending device]\ /[ending device] 331 [ending device]---[concentrator]---[concentrator]---[ending device] 332 [ending device]/ \[ending device] 333 ^ ^ ^ 334 | | | 335 Native IP TCMTF over IP Native IP 337 Figure 4 339 Such a design also allows classical compressing protocols to be used 340 on links with only a few active flows per link. 342 [ending device]\ /[ending device] 343 [ending device]---[concentrator]---[concentrator]---[ending device] 344 [ending device]/ \[ending device] 345 ^ ^ ^ 346 | | | 347 Compressed TCMTF over IP Compressed 349 Figure 5 351 2.2. Choice of the compressing protocol 353 There are different protocols that can be used for compressing real- 354 time flows: 356 o IPHC (IP Header Compression [IPHC]) permits the compression of 357 TCP/IP, UDP/IP and ESP/IP headers (Encapsulating Security Payload 358 [ESP]). It has a low implementation complexity. On the other 359 hand, the resynchronization of the context can be slow over long 360 RTT links. It should be used in scenarios presenting very low 361 packet loss percentage. 363 o cRTP (compressed RTP [cRTP]) works the same way as IPHC, but is 364 also able to compress RTP headers. The link layer transport is 365 not specified, but typically PPP is used. For cRTP to compress 366 headers, it must be implemented on each PPP link. A lot of 367 context is required to successfully run cRTP, and memory and 368 processing requirements are high, especially if multiple hops must 369 implement cRTP to save bandwidth on each of the hops. At higher 370 line rates, cRTP's processor consumption becomes prohibitively 371 expensive. cRTP is not suitable over long-delay WAN links commonly 372 used when tunneling, as proposed by this document. To avoid the 373 per-hop expense of cRTP, a simplistic solution is to use cRTP with 374 L2TP to achieve end-to-end cRTP. However, cRTP is only suitable 375 for links with low delay and low loss. However, once multiple 376 router hops are involved, cRTP's expectation of low delay and low 377 loss can no longer be met. Further, packets can arrive out of 378 order. 380 o ECRTP (Enhanced Compressed RTP [ECRTP]) is an extension of cRTP 381 [cRTP] that provides tolerance to packet loss and packet 382 reordering between compressor and decompressor. Thus, ECRTP 383 should be used instead of cRTP. 385 o ROHC (RObust Header Compression [ROHC]) is able to compress 386 TCP/IP, UDP/IP, ESP/IP and RTP/UDP/IP headers. It is a robust 387 scheme developed for header compression over links with high bit 388 error rate, such as wireless ones. It incorporates mechanisms for 389 quick resynchronization of the context. It includes an improved 390 encoding scheme for compressing the header fields that change 391 dynamically. Its main drawback is that it requires significantly 392 more processing and memory resources than the ones necessary for 393 IPHC or ECRTP. 395 This standard does not determine which of the existing protocols has 396 to be used for the compressing layer. The decision will depend on 397 the scenario, and will mainly be determined by the packet loss 398 probability, RTT, and the availability of memory and processing 399 resources. The standard is also suitable to include other 400 compressing schemes that may be further developed. 402 2.2.1. Context Synchronization in ECRTP 404 When the compressor receives an RTP packet that has an unpredicted 405 change in the RTP header, the compressor should send a COMPRESSED_UDP 406 packet (described in [ECRTP]) to synchronize the ECRTP decompressor 407 state. The COMPRESSED_UDP packet updates the RTP context in the 408 decompressor. 410 To ensure delivery of updates of context variables, COMPRESSED_UDP 411 packets should be delivered using the robust operation described in 412 [ECRTP]. 414 Because the "twice" algorithm described in [ECRTP] relies on UDP 415 checksums, the IP stack on the RTP transmitter should transmit UDP 416 checksums. If UDP checksums are not used, the ECRTP compressor 417 should use the cRTP Headers checksum described in [ECRTP]. 419 2.2.2. Context Synchronization in ROHC 421 ROHC [ROHC] includes a more complex mechanism in order to maintain 422 context synchronization. It has different operation modes and 423 defines compressor states which change depending on link behavior. 425 2.3. Multiplexing 427 Header compressing algorithms require a layer two protocol that 428 allows identifying different protocols. PPP [PPP] is suited for 429 this, although other multiplexing protocols can also be used for this 430 layer of TCMTF. 432 When header compression is used inside of a tunnel, it will reduce 433 the size of the IP, UDP, and IP headers of the IP packet carried in 434 the tunnel. However, the tunnel itself has overhead due to its IP 435 header and the tunnel header (the information necessary to identify 436 the tunneled payload). One way to reduce the overhead of the IP 437 header and tunnel header is to multiplex multiple real-time payloads 438 in a single tunneled packet. 440 2.3.1. Tunneling Inefficiencies 442 To get reasonable bandwidth efficiency using multiplexing within an 443 L2TP tunnel, multiple real-time streams should be active between the 444 source and destination of an L2TP tunnel. The packet size of the 445 real-time streams has to be small in order to permit a good bandwidth 446 saving. 448 If the source and destination of the L2TP tunnel are the same as the 449 source and destination of the compressing protocol sessions, then the 450 source and destination must have multiple active real-time streams to 451 get any benefit from multiplexing. 453 Because of this limitation, TCMTF is mostly useful for applications 454 where many real-time sessions run between a pair of endpoints. The 455 number of simultaneous sessions required to reduce the header 456 overhead to the desired level depends on the size of the L2TP header. 457 A smaller L2TP header will result in fewer simultaneous sessions 458 being required to produce adequate bandwidth efficiencies. 460 2.4. Tunneling 462 L2TP tunnels should be used to tunnel the ECRTP payloads end to end. 463 L2TP includes methods for tunneling messages used in PPP session 464 establishment, such as NCP (Network Control Protocol). This allows 465 [IPCP-HC] to negotiate ECRTP compression/decompression parameters. 467 Other tunneling schemes, such as GRE [GRE] may also be used to 468 implement the tunneling layer of TCMTF. 470 2.5. Encapsulation Formats 472 The packet format for a packet compressed is: 474 +------------+-----------------------+ 475 | | | 476 | Compr | | 477 | Header | Data | 478 | | | 479 | | | 480 +------------+-----------------------+ 482 Figure 6 484 The packet format of a multiplexed PPP packet as defined by [PPP-MUX] 485 is: 487 +-------+---+------+-------+-----+ +---+------+-------+-----+ 488 | Mux |P L| | | | |P L| | | | 489 | PPP |F X|Len1 | PPP | | |F X|LenN | PPP | | 490 | Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN| 491 | Field | | Field1| | | |FieldN | | 492 | (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | | 493 +-------+----------+-------+-----+ +----------+-------+-----+ 495 Figure 7 497 The combined format used for TCMTF with a single payload is all of 498 the above packets concatenated. Here is an example with one payload: 500 +------+------+-------+----------+-------+--------+----+ 501 | IP |Tunnel| Mux |P L| | | | | 502 |header|header| PPP |F X|Len1 | PPP | Compr | | 503 | (20) | | Proto |F T| | Proto | header |Data| 504 | | | Field | | Field1| | | 505 | | | (1) |1-2 octets| (0-2) | | | 506 +------+------+-------+----------+-------+--------+----+ 507 |<------------- IP payload -------------------->| 508 |<-------- Mux payload --------->| 510 Figure 8 512 If the tunnel contains multiplexed traffic, multiple "PPPMux 513 payload"s are transmitted in one IP packet. 515 3. Contributing Authors 517 Dan Wing 518 Cisco Systems 519 771 Alder Drive 520 San Jose, CA 95035 521 US 523 Phone: +44 7889 488 335 524 Email: dwing@cisco.com 526 Julian Fernandez-Navajas 527 University of Zaragoza 528 Dpt. IEC Ada Byron Building 529 Zaragoza, 50018 530 Spain 532 Phone: +34 976 761 963 533 Email: navajas@unizar.es 535 Jose Ruiz-Mas 536 University of Zaragoza 537 Dpt. IEC Ada Byron Building 538 Zaragoza, 50018 539 Spain 541 Phone: +34 976762158 542 Email: jruiz@unizar.es 544 Muthu Arul Mozhi Perumal 545 Cisco Systems, Inc. 546 Cessna Business Park 547 Sarjapur-Marathahalli Outer Ring Road 548 Bangalore, Karnataka 560103 549 India 551 Phone: +91 9449288768 552 Email: mperumal@cisco.com 553 Gonzalo Camarillo 554 Ericsson 555 Advanced Signalling Research Lab. 556 FIN-02420 Jorvas 557 Finland 559 Email: Gonzalo.Camarillo@ericsson.com 561 Michael A. Ramalho 562 Cisco Systems, Inc. 563 1802 Rue de la Porte 564 Wall Township, NJ 07719-3784 565 US 567 Phone: +1.732.449.5762 568 Email: mramalho@cisco.com 570 4. Acknowledgements 572 5. IANA Considerations 574 This memo includes no request to IANA. 576 6. Security Considerations 578 All drafts are required to have a security considerations section. 579 See RFC 3552 [RFC3552] for a guide. 581 7. References 583 7.1. Normative References 585 [ECRTP] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 586 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 587 High Delay, Packet Loss and Reordering", RFC 3545, 2003. 589 [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, 590 2005. 592 [FLV] ISO/IEC, "FLV and F4V File Format Specification", 593 14496-12 MPEG-4 Part 12, 2008. 595 [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 597 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 598 2000. 600 [I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 601 AAL", I. 363.2, 1997. 603 [I.711] ITU-T, "Lossless compression of G.711 pulse code 604 modulation", I. 711, 2009. 606 [IPCP-HC] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP 607 Header Compression over PPP", RFC 3544, 2003. 609 [IPHC] Degermark, M., Nordgren, B., and S. Pink, "IP Header 610 Compression", RFC 2580, 1999. 612 [L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 613 Protocol - Version 3 (L2TPv3)", RFC 3931, 2005. 615 [PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", 616 RFC 1661, 1994. 618 [PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", 619 RFC 3153, 2001. 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, March 1997. 624 [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 625 Header Compression (ROHC) Framework", RFC 4995, 2007. 627 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 628 Jacobson, "RTP: A Transport Protocol for Real-Time 629 Applications", RFC 3550, 2003. 631 [SCTP] Stewart, Ed., R., "Stream Control Transmission Protocol", 632 RFC 4960, 2007. 634 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., and et. 635 al., "SIP: Session Initiation Protocol", RFC 3261, 2005. 637 [TCRTP] Thomson, B., Koren, T., and D. Wing, "Tunneling 638 Multiplexed Compressed RTP (TCRTP)", RFC 4170, 2005. 640 [cRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 641 Headers for Low-Speed Serial Links", RFC 2508, 1999. 643 7.2. Informative References 645 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 646 Text on Security Considerations", BCP 72, RFC 3552, 647 July 2003. 649 Author's Address 651 Jose Saldana (editor) 652 University of Zaragoza 653 Dpt. IEC Ada Byron Building 654 Zaragoza, 50018 655 Spain 657 Phone: +34 976 762 698 658 Email: jsaldana@unizar.es