idnits 2.17.1 draft-saldana-tsvwg-tcmtf-03.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 641 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 (July 13, 2012) is 4305 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' ** 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 (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Transport Area Working Group J. Saldana 2 Internet-Draft University of Zaragoza 3 Obsoletes: 4170 (if approved) D. Wing 4 Intended status: BCP Cisco Systems 5 Expires: January 14, 2013 J. Fernandez Navajas 6 University of Zaragoza 7 Muthu A M. Perumal 8 Cisco Systems 9 F. Pascual Blanco 10 Telefonica I+D 11 July 13, 2012 13 Tunneling Compressed Multiplexed Traffic Flows (TCMTF) 14 draft-saldana-tsvwg-tcmtf-03 16 Abstract 18 This document describes a method to improve the bandwidth utilization 19 of network paths that carry multiple streams in parallel between two 20 endpoints, as in voice trunking. The method combines standard 21 protocols that provide compression, multiplexing, and tunneling over 22 a network path for the purpose of reducing the bandwidth used when 23 multiple streams are carried over that path. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 14, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 1.2. Bandwidth efficiency of real-time flows . . . . . . . . . 3 62 1.3. Real-time applications not using RTP . . . . . . . . . . . 4 63 1.4. Scenarios of application . . . . . . . . . . . . . . . . . 5 64 1.5. Objective of this standard . . . . . . . . . . . . . . . . 5 65 1.6. Current Standard . . . . . . . . . . . . . . . . . . . . . 6 66 1.7. Improved Standard Proposal . . . . . . . . . . . . . . . . 6 67 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8 68 2.1. Models of implementation . . . . . . . . . . . . . . . . . 8 69 2.2. Choice of the compressing protocol . . . . . . . . . . . . 9 70 2.2.1. Context Synchronization in ECRTP . . . . . . . . . . . 10 71 2.2.2. Context Synchronization in ROHC . . . . . . . . . . . 10 72 2.3. Multiplexing . . . . . . . . . . . . . . . . . . . . . . . 10 73 2.3.1. Tunneling Inefficiencies . . . . . . . . . . . . . . . 11 74 2.4. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 11 75 2.4.1. Tunneling schemes over IP: L2TP and GRE . . . . . . . 11 76 2.4.2. MPLS tunneling . . . . . . . . . . . . . . . . . . . . 11 77 2.5. Encapsulation Formats . . . . . . . . . . . . . . . . . . 12 78 3. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13 79 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 This document describes a way to combine existing protocols for 90 compression, multiplexing, and tunneling to save bandwidth for some 91 applications that generate small packets, such as real-time ones. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 1.2. Bandwidth efficiency of real-time flows 101 In the last years we are witnessing the raise of new real-time 102 services that use the Internet for the delivery of interactive 103 multimedia applications. The most common of these services is VoIP, 104 but many others have been developed, and are experiencing a 105 significant growth: videoconferencing, telemedicine, video vigilance, 106 online gaming, etc. 108 The first design of the Internet did not include any mechanism 109 capable of guaranteeing an upper bound for delivery delay, taking 110 into account that the first deployed services were e-mail, file 111 transfer, etc., in which delay is not critical. RTP [RTP] was first 112 defined in 1996 in order to permit the delivery of real-time 113 contents. Nowadays, although there are a variety of protocols used 114 for signaling real-time flows (SIP [SIP], H.323, etc.), RTP has 115 become the standard par excellence for the delivery of real-time 116 content. 118 RTP was designed to work over UDP datagrams. This implies that an 119 IPv4 packet carrying real-time information has to include 40 bytes of 120 headers: 20 for IPv4 header, 8 for UDP, and 12 for RTP. This 121 overhead is significant, taking into account that many real-time 122 services send very small payloads. It becomes even more significant 123 with IPv6 packets, as the basic IPv6 header is twice the size of the 124 IPv4 header (Table 1). 126 +---------------------------------+---------------------------------+ 127 | IPv4 | IPv6 | 128 +---------------------------------+---------------------------------+ 129 | IPv4+UDP+RTP: 40 bytes header | IPv6+UDP+RTP: 60 bytes header | 130 | G.711 at 20 ms packetization: | G.711 at 20 ms packetization: | 131 | 25% header overhead | 37.5% header overhead | 132 | G.729 at 20 ms packetization: | G.729 at 20 ms packetization: | 133 | 200% header overhead | 300% header overhead | 134 +---------------------------------+---------------------------------+ 136 Table 1: Efficiency of different voice codecs 138 In order to mitigate this bad network efficiency, the multiplexing of 139 a number of payloads into a single packet can be considered as a 140 solution. If we have only one flow, the number of samples included 141 in a packet can be increased, but at the cost of adding new 142 packetization delays. However, if a number of flows share the same 143 path between an origin and a destination, a multiplexer can build a 144 bigger packet in which a number of payloads share a common header. A 145 demultiplexer is necessary at the end of the common path, so as to 146 rebuild the packets as they were originally sent, making multiplexing 147 a transparent process for the extremes of the flow. 149 The headers of the original packets can be compressed to save more 150 bandwidth, taking into account that there exist some header 151 compressing standards ([cRTP], [ECRTP], [IPHC], [ROHC]). When 152 different headers are compressed together, tunneling can be used to 153 relieve intermediate routers from the decompression and compression 154 processing. 156 1.3. Real-time applications not using RTP 158 But there are many real-time applications that do not use RTP. Some 159 of them send UDP packets, e.g. First Person Shooter (FPS) online 160 games, for which latency is very critical. There is also another 161 fact which has to be taken into account: TCP is getting used for 162 media delivery. For many reasons, such as avoiding firewalls, the 163 standard RTP/UDP/IP protocol stack is substituted in many cases by 164 FLV/HTTP/TCP/IP (FLash Video [FLV]). 166 There is also another kind of applications which have been reported 167 as real-time using TCP: MMORPGs (Massively Multiplayer Online Role 168 Playing Games), which in some cases have millions of players, 169 thousands of them sharing the same virtual world. They use TCP 170 packets to send the player commands to the server, and also to send 171 to the player's application the characteristics and situation of 172 other gamers' avatars. These games do not have the same 173 interactivity of FPSs, but the quickness and the movements of the 174 player are important, and can decide if they win or lose a fight. 176 1.4. Scenarios of application 178 Different scenarios of application can be considered for the 179 tunneling, compressing and multiplexing solution: for example, voice 180 trunking between gateways of different offices of an enterprise. 181 Also, the traffic of the users of an application in a town or a 182 district, which can be multiplexed and sent to the central server. 183 Also Internet cafes are suitable of having many users of the same 184 application (e.g. a game) sharing the same access link. 186 Another interesting scenario are satellite communication links that 187 often manage the bandwidth by limiting the transmission rate, 188 measured in packets per second (pps), to and from the satellite. 189 Applications like VoIP that generate a large number of small packets 190 can easily fill the maximum number of pps slots, limiting the 191 throughput across such links. As an example, a G.729a voice call 192 generates 50 pps at 20 ms packetization time. If the satellite 193 transmission allows 1,500 pps, the number of simultaneous voice calls 194 is limited to 30. This results in poor utilization of the satellite 195 link's bandwidth as well as places a low bound on the number of voice 196 calls that can utilize the link simultaneously. Multiplexing small 197 packets into one packet for transmission would improve the 198 efficiency. Satellite links would also find it useful to multiplex 199 small TCP packets into one packet. This could be especially 200 interesting for compressing TCP ACKs. 202 There is still another interesting use case: desktop or application 203 sharing where the traffic from the server to the client typically 204 consists of the delta of screen updates. Also, the standard for 205 remote desktop sharing emerging for WebRTC in the RTCWEB Working 206 Group is: {something}/SCTP/UDP (Stream Control Transmission Protocol 207 [SCTP]). In this scenario, SCTP/UDP could be used in other cases: 208 chatting, file sharing and applications related to WebRTC peers. 209 There could be hundreds of clients at a site talking to a server 210 located at a datacenter over a WAN. Compressing, multiplexing and 211 tunneling this traffic could save WAN bandwidth and potentially 212 improve latency. 214 1.5. Objective of this standard 216 In conclusion, a standard that multiplexes, compresses and sends 217 packets using a tunnel can be interesting for many enterprises: 218 developers of VoIP systems can include this option in their 219 solutions; or game providers, who can achieve bandwidth savings in 220 their supporting infrastructures. Other fact that has to be taken 221 into account is that the technique not only saves bandwidth but also 222 reduces the number of packets per second, which sometimes can be a 223 bottleneck for a satellite link or even for a network router. 225 If only one stream is tunneled and compressed, then little bandwidth 226 savings will be obtained. In contrast, multiplexing is helpful to 227 amortize the overhead of the tunnel header over many payloads. 229 1.6. Current Standard 231 The current standard [TCRTP] defines a way to reduce bandwidth and 232 pps of RTP traffic, by combining three different standard protocols: 234 o Regarding compression, [ECRTP] is the selected option. 236 o Multiplexing is accomplished using PPP Multiplexing [PPP-MUX] 238 o Tunneling is accomplished by using L2TP (Layer 2 Tunneling 239 Protocol [L2TPv3]). 241 The three layers are combined as shown in the figure: 243 RTP/UDP 244 | 245 | ---------------------------- 246 | 247 ECRTP compressing layer 248 | 249 | ---------------------------- 250 | 251 PPPMUX multiplexing layer 252 | 253 | ---------------------------- 254 | 255 L2TP tunneling layer 256 | 257 | ---------------------------- 258 | 259 IP 261 Figure 1 263 1.7. Improved Standard Proposal 265 In contrast to the current standard [TCRTP], the new proposal allows 266 the compression of other protocols in addition to RTP/UDP, since 267 real-time services are also provided by bare UDP or TCP, as shown in 268 the figure: 270 TCP UDP RTP/UDP 271 | | | 272 \ | / ------------------------------ 273 \ | / 274 Nothing or ROHC or ECRTP or IPHC header compressing layer 275 | 276 | ------------------------------ 277 | 278 PPPMUX or other mux protocols multiplexing layer 279 | 280 / \ ------------------------------ 281 / \ 282 / \ 283 GRE or L2TP \ tunneling layer 284 | MPLS 285 | ------------------------------ 286 IP 288 Figure 2 290 Each of the three layers is considered as independent of the other 291 two, i.e. different combinations of protocols can be implemented 292 according to the new proposal: 294 o Regarding compression, a number of options can be considered: as 295 different standards are able to compress different headers 296 ([cRTP], [ECRTP], [IPHC], [ROHC]). The one to be used could be 297 selected depending on the traffic to compress and the concrete 298 scenario (packet loss percentage, delay, etc.). It also exists 299 the possibility of having a null header compression, in the case 300 of wanting to avoid traffic compression, taking into account the 301 need of storing a context for every flow and the problems of 302 context desynchronization in certain scenarios. 304 o Multiplexing is also accomplished using PPP Multiplexing 305 [PPP-MUX]. Nevertheless, other multiplexing protocols can also be 306 considered. 308 o Tunneling is accomplished by using L2TP (Layer 2 Tunneling 309 Protocol [L2TPv3]) over IP, GRE (Generic Routing Encapsulation 310 [GRE]) over IP, or MPLS (Multiprotocol Label Switching 311 Architecture [MPLS]). 313 Payload compression schemes could also be used, but they are not the 314 aim of this standard. 316 2. Protocol Operation 318 This section describes how to combine three protocols: compressing, 319 multiplexing, and tunneling, to save bandwidth for real-time 320 applications. 322 2.1. Models of implementation 324 TCMTF can be implemented in different ways. The most straightforward 325 is to implement it in the devices terminating the real-time streams 326 (these devices can be e.g. voice gateways, or proxies grouping a 327 number of flows): 329 [ending device]---[ending device] 330 ^ 331 | 332 TCMTF over IP 334 Figure 3 336 Another way TCMTF can be implemented is with an external 337 concentration device. This device could be placed at strategic 338 places in the network and could dynamically create and destroy TCMTF 339 sessions without the participation of the endpoints that generate 340 real-time flows. 342 [ending device]\ /[ending device] 343 [ending device]---[concentrator]---[concentrator]---[ending device] 344 [ending device]/ \[ending device] 345 ^ ^ ^ 346 | | | 347 Native IP TCMTF over IP Native IP 349 Figure 4 351 A number of already compressed flows can also be merged in a tunnel 352 using a concentrator in order to increase the number of flows in a 353 tunnel: 355 [ending device]\ /[ending device] 356 [ending device]---[concentrator]---[concentrator]---[ending device] 357 [ending device]/ \[ending device] 358 ^ ^ ^ 359 | | | 360 Compressed TCMTF over IP Compressed 362 Figure 5 364 2.2. Choice of the compressing protocol 366 There are different protocols that can be used for compressing real- 367 time flows: 369 o IPHC (IP Header Compression [IPHC]) permits the compression of 370 TCP/IP, UDP/IP and ESP/IP headers (Encapsulating Security Payload 371 [ESP]). It has a low implementation complexity. On the other 372 hand, the resynchronization of the context can be slow over long 373 RTT links. It should be used in scenarios presenting very low 374 packet loss percentage. 376 o cRTP (compressed RTP [cRTP]) works the same way as IPHC, but is 377 also able to compress RTP headers. The link layer transport is 378 not specified, but typically PPP is used. For cRTP to compress 379 headers, it must be implemented on each PPP link. A lot of 380 context is required to successfully run cRTP, and memory and 381 processing requirements are high, especially if multiple hops must 382 implement cRTP to save bandwidth on each of the hops. At higher 383 line rates, cRTP's processor consumption becomes prohibitively 384 expensive. cRTP is not suitable over long-delay WAN links commonly 385 used when tunneling, as proposed by this document. To avoid the 386 per-hop expense of cRTP, a simplistic solution is to use cRTP with 387 L2TP to achieve end-to-end cRTP. However, cRTP is only suitable 388 for links with low delay and low loss. Thus, if multiple router 389 hops are involved, cRTP's expectation of low delay and low loss 390 can no longer be met. Further, packets can arrive out of order. 392 o ECRTP (Enhanced Compressed RTP [ECRTP]) is an extension of cRTP 393 [cRTP] that provides tolerance to packet loss and packet 394 reordering between compressor and decompressor. Thus, ECRTP 395 should be used instead of cRTP. 397 o ROHC (RObust Header Compression [ROHC]) is able to compress 398 TCP/IP, UDP/IP, ESP/IP and RTP/UDP/IP headers. It is a robust 399 scheme developed for header compression over links with high bit 400 error rate, such as wireless ones. It incorporates mechanisms for 401 quick resynchronization of the context. It includes an improved 402 encoding scheme for compressing the header fields that change 403 dynamically. Its main drawback is that it requires significantly 404 more processing and memory resources than the ones necessary for 405 IPHC or ECRTP. 407 This standard does not determine which of the existing protocols has 408 to be used for the compressing layer. The decision will depend on 409 the scenario, and will mainly be determined by the packet loss 410 probability, RTT, and the availability of memory and processing 411 resources. The standard is also suitable to include other 412 compressing schemes that may be further developed. 414 2.2.1. Context Synchronization in ECRTP 416 When the compressor receives an RTP packet that has an unpredicted 417 change in the RTP header, the compressor should send a COMPRESSED_UDP 418 packet (described in [ECRTP]) to synchronize the ECRTP decompressor 419 state. The COMPRESSED_UDP packet updates the RTP context in the 420 decompressor. 422 To ensure delivery of updates of context variables, COMPRESSED_UDP 423 packets should be delivered using the robust operation described in 424 [ECRTP]. 426 Because the "twice" algorithm described in [ECRTP] relies on UDP 427 checksums, the IP stack on the RTP transmitter should transmit UDP 428 checksums. If UDP checksums are not used, the ECRTP compressor 429 should use the cRTP Header checksum described in [ECRTP]. 431 2.2.2. Context Synchronization in ROHC 433 ROHC [ROHC] includes a more complex mechanism in order to maintain 434 context synchronization. It has different operation modes and 435 defines compressor states which change depending on link behavior. 437 2.3. Multiplexing 439 Header compressing algorithms require a layer two protocol that 440 allows identifying different protocols. PPP [PPP] is suited for 441 this, although other multiplexing protocols can also be used for this 442 layer of TCMTF. 444 When header compression is used inside of a tunnel, it will reduce 445 the size of the headers of the IP packet carried in the tunnel. 446 However, the tunnel itself has overhead due to its IP header and the 447 tunnel header (the information necessary to identify the tunneled 448 payload). One way to reduce the overhead of the IP and tunnel 449 headers is to multiplex multiple real-time payloads in a single 450 tunneled packet. 452 2.3.1. Tunneling Inefficiencies 454 To get reasonable bandwidth efficiency using multiplexing within a 455 tunnel, multiple real-time streams should be active between the 456 source and destination of an L2TP tunnel. The packet size of the 457 real-time streams has to be small in order to permit a good bandwidth 458 saving. 460 If the source and destination of the tunnel are the same as the 461 source and destination of the compressing protocol sessions, then the 462 source and destination must have multiple active real-time streams to 463 get any benefit from multiplexing. 465 Because of this limitation, TCMTF is mostly useful for applications 466 where many real-time sessions run between a pair of endpoints. The 467 number of simultaneous sessions required to reduce the header 468 overhead to the desired level depends on the size of the tunnel 469 header. A smaller tunnel header will result in fewer simultaneous 470 sessions being required to produce adequate bandwidth efficiencies. 472 2.4. Tunneling 474 Different tunneling schemes can be used for sending end to end the 475 compressed payloads. 477 2.4.1. Tunneling schemes over IP: L2TP and GRE 479 L2TP tunnels should be used to tunnel the compressed payloads end to 480 end. L2TP includes methods for tunneling messages used in PPP 481 session establishment, such as NCP (Network Control Protocol). This 482 allows [IPCP-HC] to negotiate ECRTP compression/decompression 483 parameters. 485 Other tunneling schemes, such as GRE [GRE] may also be used to 486 implement the tunneling layer of TCMTF. 488 2.4.2. MPLS tunneling 490 In some scenarios, mainly in operator's core networks, the use of 491 MPLS is widely deployed as data transport method. The adoption of 492 MPLS as tunneling layer in this proposal intends to natively adapt 493 TCMTF to those transport networks. 495 In the same way that layer 3 tunnels, MPLS paths, identified by MPLS 496 labels, established between Label Edge Routers (LSRs), could be used 497 to transport the compressed payloads within an MPLS network. This 498 way, multiplexing layer must be placed over MPLS layer. Note that, 499 in this case, layer 3 tunnel headers do not have to be used, with the 500 consequent data efficiency improvement. 502 2.5. Encapsulation Formats 504 The packet format for a packet compressed is: 506 +------------+-----------------------+ 507 | | | 508 | Compr | | 509 | Header | Data | 510 | | | 511 | | | 512 +------------+-----------------------+ 514 Figure 6 516 The packet format of a multiplexed PPP packet as defined by [PPP-MUX] 517 is: 519 +-------+---+------+-------+-----+ +---+------+-------+-----+ 520 | Mux |P L| | | | |P L| | | | 521 | PPP |F X|Len1 | PPP | | |F X|LenN | PPP | | 522 | Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN| 523 | Field | | Field1| | | |FieldN | | 524 | (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | | 525 +-------+----------+-------+-----+ +----------+-------+-----+ 527 Figure 7 529 The combined format used for TCMTF with a single payload is all of 530 the above packets concatenated. Here is an example with one payload, 531 using L2TP or GRE tunneling: 533 +------+------+-------+----------+-------+--------+----+ 534 | IP |Tunnel| Mux |P L| | | | | 535 |header|header| PPP |F X|Len1 | PPP | Compr | | 536 | (20) | | Proto |F T| | Proto | header |Data| 537 | | | Field | | Field1| | | 538 | | | (1) |1-2 octets| (0-2) | | | 539 +------+------+-------+----------+-------+--------+----+ 540 |<------------- IP payload -------------------->| 541 |<-------- Mux payload --------->| 543 Figure 8 545 If the tunneling technology is MPLS, then the scheme would be: 547 +------+-------+----------+-------+--------+----+ 548 |MPLS | Mux |P L| | | | | 549 |header| PPP |F X|Len1 | PPP | Compr | | 550 | | Proto |F T| | Proto | header |Data| 551 | | Field | | Field1| | | 552 | | (1) |1-2 octets| (0-2) | | | 553 -+------+-------+----------+-------+--------+----+ 554 |<---------- MPLS payload -------------->| 555 |<-------- Mux payload --------->| 557 Figure 9 559 If the tunnel contains multiplexed traffic, multiple "PPPMux 560 payload"s are transmitted in one IP packet. 562 3. Contributing Authors 564 Gonzalo Camarillo 565 Ericsson 566 Advanced Signalling Research Lab. 567 FIN-02420 Jorvas 568 Finland 570 Email: Gonzalo.Camarillo@ericsson.com 571 Michael A. Ramalho 572 Cisco Systems, Inc. 573 4564 Tuscana Drive 574 Sarasota, FL 34241-4201 575 US 577 Phone: +1.732.449.5762 578 Email: mramalho@cisco.com 580 Jose Ruiz Mas 581 University of Zaragoza 582 Dpt. IEC Ada Byron Building 583 50018 Zaragoza 584 Spain 586 Phone: +34 976762158 587 Email: jruiz@unizar.es 589 Diego Lopez Garcia 590 Telefonica I+D 591 Ramon de la cruz 84 592 28006 Madrid 593 Spain 595 Phone: +34 913129041 596 Email: diego@tid.es 598 David Florez Rodriguez 599 Telefonica I+D 600 Ramon de la cruz 84 601 28006 Madrid 602 Spain 604 Phone: +34 91312884 605 Email: dflorez@tid.es 607 Manuel Nunez Sanz 608 Telefonica I+D 609 Ramon de la cruz 84 610 28006 Madrid 611 Spain 613 Phone: +34 913128821 614 Email: mns@tid.es 615 Juan Antonio Castell Lucia 616 Telefonica I+D 617 Ramon de la cruz 84 618 28006 Madrid 619 Spain 621 Phone: +34 913129157 622 Email: jacl@tid.es 624 4. Acknowledgements 626 5. IANA Considerations 628 This memo includes no request to IANA. 630 6. Security Considerations 632 All drafts are required to have a security considerations section. 633 See RFC 3552 [RFC3552] for a guide. 635 7. References 637 7.1. Normative References 639 [ECRTP] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 640 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 641 High Delay, Packet Loss and Reordering", RFC 3545, 2003. 643 [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, 644 2005. 646 [FLV] ISO/IEC, "FLV and F4V File Format Specification", 647 14496-12 MPEG-4 Part 12, 2008. 649 [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 650 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 651 2000. 653 [I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 654 AAL", I. 363.2, 1997. 656 [IPCP-HC] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP 657 Header Compression over PPP", RFC 3544, 2003. 659 [IPHC] Degermark, M., Nordgren, B., and S. Pink, "IP Header 660 Compression", RFC 2580, 1999. 662 [L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 663 Protocol - Version 3 (L2TPv3)", RFC 3931, 2005. 665 [MPLS] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 666 Label Switching Architecture", RFC 3031, January 2001. 668 [PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", 669 RFC 1661, 1994. 671 [PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", 672 RFC 3153, 2001. 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, March 1997. 677 [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 678 Header Compression (ROHC) Framework", RFC 4995, 2007. 680 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 681 Jacobson, "RTP: A Transport Protocol for Real-Time 682 Applications", RFC 3550, 2003. 684 [SCTP] Stewart, Ed., R., "Stream Control Transmission Protocol", 685 RFC 4960, 2007. 687 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., and et. 688 al., "SIP: Session Initiation Protocol", RFC 3261, 2005. 690 [TCRTP] Thomson, B., Koren, T., and D. Wing, "Tunneling 691 Multiplexed Compressed RTP (TCRTP)", RFC 4170, 2005. 693 [cRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 694 Headers for Low-Speed Serial Links", RFC 2508, 1999. 696 7.2. Informative References 698 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 699 Text on Security Considerations", BCP 72, RFC 3552, 700 July 2003. 702 Authors' Addresses 704 Jose Saldana 705 University of Zaragoza 706 Dpt. IEC Ada Byron Building 707 Zaragoza, 50018 708 Spain 710 Phone: +34 976 762 698 711 Email: jsaldana@unizar.es 713 Dan Wing 714 Cisco Systems 715 771 Alder Drive 716 San Jose, CA 95035 717 US 719 Phone: +44 7889 488 335 720 Email: dwing@cisco.com 722 Julian Fernandez Navajas 723 University of Zaragoza 724 Dpt. IEC Ada Byron Building 725 Zaragoza, 50018 726 Spain 728 Phone: +34 976 761 963 729 Email: navajas@unizar.es 731 Muthu Arul Mozhi Perumal 732 Cisco Systems 733 Cessna Business Park 734 Sarjapur-Marathahalli Outer Ring Road 735 Bangalore, Karnataka 560103 736 India 738 Phone: +91 9449288768 739 Email: mperumal@cisco.com 740 Fernando Pascual Blanco 741 Telefonica I+D 742 Ramon de la Cruz 84 743 Madrid, 28006 744 Spain 746 Phone: +34 913128779 747 Email: fpb@tid.es