idnits 2.17.1 draft-saldana-tsvwg-tcmtf-02.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 559 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 (March 2, 2012) is 4437 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: September 3, 2012 J. Fernandez Navajas 6 University of Zaragoza 7 Muthu A M. Perumal 8 Cisco Systems 9 J. Ruiz Mas 10 University of Zaragoza 11 March 2, 2012 13 Tunneling Compressed Multiplexed Traffic Flows (TCMTF) 14 draft-saldana-tsvwg-tcmtf-02 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 September 3, 2012. 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 . . . . . . . . . . . . . . . . . . . . . . 7 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.5. Encapsulation Formats . . . . . . . . . . . . . . . . . . 11 76 3. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 13 77 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 This document describes a way to combine existing protocols for 88 compression, multiplexing, and tunneling to save bandwidth for some 89 applications that generate small packets, such as real-time ones. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 1.2. Bandwidth efficiency of real-time flows 99 In the last years we are witnessing the raise of new real-time 100 services that use the Internet for the delivery of interactive 101 multimedia applications. The most common of these services is VoIP, 102 but many others have been developed, and are experiencing a 103 significant growth: videoconferencing, telemedicine, video vigilance, 104 online gaming, etc. 106 The first design of the Internet did not include any mechanism 107 capable of guaranteeing an upper bound for delivery delay, taking 108 into account that the first deployed services were e-mail, file 109 transfer, etc., in which delay is not critical. RTP [RTP] was first 110 defined in 1996 in order to permit the delivery of real-time 111 contents. Nowadays, although there are a variety of protocols used 112 for signaling real-time flows (SIP [SIP], H.323, etc.), RTP has 113 become the standard par excellence for the delivery of real-time 114 content. 116 RTP was designed to work over UDP datagrams. This implies that an 117 IPv4 packet carrying real-time information has to include 40 bytes of 118 headers: 20 for IPv4 header, 8 for UDP, and 12 for RTP. This 119 overhead is significant, taking into account that many real-time 120 services send very small payloads. It becomes even more significant 121 with IPv6 packets, as the basic IPv6 header is twice the size of the 122 IPv4 header (Table 1). 124 +---------------------------------+---------------------------------+ 125 | IPv4 | IPv6 | 126 +---------------------------------+---------------------------------+ 127 | IPv4+UDP+RTP: 40 bytes header | IPv6+UDP+RTP: 60 bytes header | 128 | G.711 at 20 ms packetization: | G.711 at 20 ms packetization: | 129 | 25% header overhead | 37.5% header overhead | 130 | G.729 at 20 ms packetization: | G.729 at 20 ms packetization: | 131 | 200% header overhead | 300% header overhead | 132 +---------------------------------+---------------------------------+ 134 Table 1: Efficiency of different voice codecs 136 In order to mitigate this bad network efficiency, the multiplexing of 137 a number of payloads into a single packet can be considered as a 138 solution. If we have only one flow, the number of samples included 139 in a packet can be increased, but at the cost of adding new 140 packetization delays. However, if a number of flows share the same 141 path between an origin and a destination, a multiplexer can build a 142 bigger packet in which a number of payloads share a common header. A 143 demultiplexer is necessary at the end of the common path, so as to 144 rebuild the packets as they were originally sent, making multiplexing 145 a transparent process for the extremes of the flow. 147 The headers of the original packets can be compressed to save more 148 bandwidth, taking into account that there exist some header 149 compressing standards ([cRTP], [ECRTP], [IPHC], [ROHC]). When 150 different headers are compressed together, tunneling can be used to 151 relieve intermediate routers from the decompression and compression 152 processing. 154 1.3. Real-time applications not using RTP 156 But there are many real-time applications that do not use RTP. Some 157 of them send UDP packets, e.g. First Person Shooter (FPS) online 158 games, for which latency is very critical. There is also another 159 fact which has to be taken into account: TCP is getting used for 160 media delivery. For many reasons, such as avoiding firewalls, the 161 standard RTP/UDP/IP protocol stack is substituted in many cases by 162 FLV/HTTP/TCP/IP (FLash Video [FLV]). 164 There is also another kind of applications which have been reported 165 as real-time using TCP: MMORPGs (Massively Multiplayer Online Role 166 Playing Games), which in some cases have millions of players, 167 thousands of them sharing the same virtual world. They use TCP 168 packets to send the player commands to the server, and also to send 169 to the player's application the characteristics and situation of 170 other gamers' avatars. These games do not have the same 171 interactivity of FPSs, but the quickness and the movements of the 172 player are important, and can decide if they win or lose a fight. 174 1.4. Scenarios of application 176 Different scenarios of application can be considered for the 177 tunneling, compressing and multiplexing solution: for example, voice 178 trunking between gateways of different offices of an enterprise. 179 Also, the traffic of the users of an application in a town or a 180 district, which can be multiplexed and sent to the central server. 181 Also Internet cafes are suitable of having many users of the same 182 application (e.g. a game) sharing the same access link. 184 Another interesting scenario are satellite communication links that 185 often manage the bandwidth by limiting the transmission rate, 186 measured in packets per second (pps), to and from the satellite. 187 Applications like VoIP that generate a large number of small packets 188 can easily fill the limited number of pps slots, limiting the 189 throughput across such links. As an example, a G.729a voice call 190 generates 50 pps at 20 ms packetization time. If the satellite 191 transmission allows 1,500 pps, the number of simultaneous voice calls 192 is limited to 30. This results in poor utilization of the satellite 193 link's bandwidth as well as places a low bound on the number of voice 194 calls that can utilize the link simultaneously. Multiplexing small 195 packets into one packet for transmission would improve the 196 efficiency. Satellite links would also find it useful to multiplex 197 small TCP packets into one packet. This could be especially 198 interesting for compressing TCP ACKs. 200 There is still another interesting use case: desktop or application 201 sharing where the traffic from the server to the client typically 202 consists of the delta of screen updates. Also, the standard for 203 remote desktop sharing emerging for WebRTC in the RTCWEB Working 204 Group is: {something}/SCTP/UDP (Stream Control Transmission Protocol 205 [SCTP]). In this scenario, SCTP/UDP could be used in other cases: 206 chatting, file sharing and applications related to WebRTC peers. 207 There could be hundreds of clients at a site talking to a server 208 located at a datacenter over a WAN. Compressing, multiplexing and 209 tunneling this traffic could save WAN bandwidth and potentially 210 improve latency. 212 1.5. Objective of this standard 214 In conclusion, a standard that multiplexes, compresses and sends 215 packets using a tunnel can be interesting for many enterprises: 216 developers of VoIP systems can include this option in their 217 solutions; or game providers, who can achieve bandwidth savings in 218 their supporting infrastructures. Other fact that has to be taken 219 into account is that the technique not only saves bandwidth but also 220 reduces the number of packets per second, which sometimes can be a 221 bottleneck for a satellite link or even for a network router. 223 If only one stream is tunneled and compressed, then little bandwidth 224 savings will be obtained. In contrast, multiplexing is helpful to 225 amortize the overhead of the tunnel header over many payloads. 227 1.6. Current Standard 229 The current standard [TCRTP] defines a way to reduce bandwidth and 230 pps of RTP traffic, by combining three different standard protocols: 232 o Regarding compression, [ECRTP] is the selected option. 234 o Multiplexing is accomplished using PPP Multiplexing [PPP-MUX] 236 o Tunneling is accomplished by using L2TP (Layer 2 Tunneling 237 Protocol [L2TPv3]). 239 The three layers are combined as shown in the figure: 241 RTP/UDP 242 | 243 | ---------------------------- 244 | 245 ECRTP compressing layer 246 | 247 | ---------------------------- 248 | 249 PPPMUX multiplexing layer 250 | 251 | ---------------------------- 252 | 253 L2TP tunneling layer 254 | 255 | ---------------------------- 256 | 257 IP 259 Figure 1 261 1.7. Improved Standard Proposal 263 In contrast to the current standard [TCRTP], the new proposal allows 264 the compression of other protocols in addition to RTP/UDP, since 265 real-time services are also provided by bare UDP or TCP, as shown in 266 the figure: 268 TCP UDP RTP/UDP 269 | | | 270 \ | / ------------------------------ 271 \ | / 272 Nothing or ROHC or ECRTP or IPHC header compressing layer 273 | 274 | ------------------------------ 275 | 276 PPPMUX or other mux protocols multiplexing layer 277 | 278 | ------------------------------ 279 | 280 GRE or L2TP or other tunneling layer 281 | 282 | ------------------------------ 283 IP 285 Figure 2 287 Each of the three layers is considered as independent of the other 288 two, i.e. different combinations of protocols can be implemented 289 according to the new proposal: 291 o Regarding compression, a number of options can be considered: as 292 different standards are able to compress different headers 293 ([cRTP], [ECRTP], [IPHC], [ROHC]). The one to be used could be 294 selected depending on the traffic to compress and the concrete 295 scenario (packet loss percentage, delay, etc.). It also exists 296 the possibility of having a null header compression, in the case 297 of wanting to avoid traffic compression, taking into account the 298 need of storing a context for every flow and the problems of 299 context desynchronization in certain scenarios. 301 o Multiplexing is also accomplished using PPP Multiplexing 302 [PPP-MUX]. Nevertheless, other multiplexing protocols can also be 303 considered. 305 o Tunneling is accomplished by using L2TP (Layer 2 Tunneling 306 Protocol [L2TPv3]), GRE (Generic Routing Encapsulation [GRE]) or 307 other schemes. 309 Payload compression schemes could also be used, but they are not the 310 aim of this standard. 312 2. Protocol Operation 314 This section describes how to combine three protocols: compressing, 315 multiplexing, and tunneling, to save bandwidth for real-time 316 applications. 318 2.1. Models of implementation 320 TCMTF can be implemented in different ways. The most straightforward 321 is to implement it in the devices terminating the real-time streams 322 (these devices can be e.g. voice gateways, or proxies grouping a 323 number of flows): 325 [ending device]---[ending device] 326 ^ 327 | 328 TCMTF over IP 330 Figure 3 332 Another way TCMTF can be implemented is with an external 333 concentration device. This device could be placed at strategic 334 places in the network and could dynamically create and destroy TCMTF 335 sessions without the participation of the endpoints that generate 336 real-time flows. 338 [ending device]\ /[ending device] 339 [ending device]---[concentrator]---[concentrator]---[ending device] 340 [ending device]/ \[ending device] 341 ^ ^ ^ 342 | | | 343 Native IP TCMTF over IP Native IP 345 Figure 4 347 Such a design also allows classical compressing protocols to be used 348 on links with only a few active flows per link. 350 [ending device]\ /[ending device] 351 [ending device]---[concentrator]---[concentrator]---[ending device] 352 [ending device]/ \[ending device] 353 ^ ^ ^ 354 | | | 355 Compressed TCMTF over IP Compressed 357 Figure 5 359 2.2. Choice of the compressing protocol 361 There are different protocols that can be used for compressing real- 362 time flows: 364 o IPHC (IP Header Compression [IPHC]) permits the compression of 365 TCP/IP, UDP/IP and ESP/IP headers (Encapsulating Security Payload 366 [ESP]). It has a low implementation complexity. On the other 367 hand, the resynchronization of the context can be slow over long 368 RTT links. It should be used in scenarios presenting very low 369 packet loss percentage. 371 o cRTP (compressed RTP [cRTP]) works the same way as IPHC, but is 372 also able to compress RTP headers. The link layer transport is 373 not specified, but typically PPP is used. For cRTP to compress 374 headers, it must be implemented on each PPP link. A lot of 375 context is required to successfully run cRTP, and memory and 376 processing requirements are high, especially if multiple hops must 377 implement cRTP to save bandwidth on each of the hops. At higher 378 line rates, cRTP's processor consumption becomes prohibitively 379 expensive. cRTP is not suitable over long-delay WAN links commonly 380 used when tunneling, as proposed by this document. To avoid the 381 per-hop expense of cRTP, a simplistic solution is to use cRTP with 382 L2TP to achieve end-to-end cRTP. However, cRTP is only suitable 383 for links with low delay and low loss. However, once multiple 384 router hops are involved, cRTP's expectation of low delay and low 385 loss can no longer be met. Further, packets can arrive out of 386 order. 388 o ECRTP (Enhanced Compressed RTP [ECRTP]) is an extension of cRTP 389 [cRTP] that provides tolerance to packet loss and packet 390 reordering between compressor and decompressor. Thus, ECRTP 391 should be used instead of cRTP. 393 o ROHC (RObust Header Compression [ROHC]) is able to compress 394 TCP/IP, UDP/IP, ESP/IP and RTP/UDP/IP headers. It is a robust 395 scheme developed for header compression over links with high bit 396 error rate, such as wireless ones. It incorporates mechanisms for 397 quick resynchronization of the context. It includes an improved 398 encoding scheme for compressing the header fields that change 399 dynamically. Its main drawback is that it requires significantly 400 more processing and memory resources than the ones necessary for 401 IPHC or ECRTP. 403 This standard does not determine which of the existing protocols has 404 to be used for the compressing layer. The decision will depend on 405 the scenario, and will mainly be determined by the packet loss 406 probability, RTT, and the availability of memory and processing 407 resources. The standard is also suitable to include other 408 compressing schemes that may be further developed. 410 2.2.1. Context Synchronization in ECRTP 412 When the compressor receives an RTP packet that has an unpredicted 413 change in the RTP header, the compressor should send a COMPRESSED_UDP 414 packet (described in [ECRTP]) to synchronize the ECRTP decompressor 415 state. The COMPRESSED_UDP packet updates the RTP context in the 416 decompressor. 418 To ensure delivery of updates of context variables, COMPRESSED_UDP 419 packets should be delivered using the robust operation described in 420 [ECRTP]. 422 Because the "twice" algorithm described in [ECRTP] relies on UDP 423 checksums, the IP stack on the RTP transmitter should transmit UDP 424 checksums. If UDP checksums are not used, the ECRTP compressor 425 should use the cRTP Headers checksum described in [ECRTP]. 427 2.2.2. Context Synchronization in ROHC 429 ROHC [ROHC] includes a more complex mechanism in order to maintain 430 context synchronization. It has different operation modes and 431 defines compressor states which change depending on link behavior. 433 2.3. Multiplexing 435 Header compressing algorithms require a layer two protocol that 436 allows identifying different protocols. PPP [PPP] is suited for 437 this, although other multiplexing protocols can also be used for this 438 layer of TCMTF. 440 When header compression is used inside of a tunnel, it will reduce 441 the size of the IP, UDP, and IP headers of the IP packet carried in 442 the tunnel. However, the tunnel itself has overhead due to its IP 443 header and the tunnel header (the information necessary to identify 444 the tunneled payload). One way to reduce the overhead of the IP 445 header and tunnel header is to multiplex multiple real-time payloads 446 in a single tunneled packet. 448 2.3.1. Tunneling Inefficiencies 450 To get reasonable bandwidth efficiency using multiplexing within an 451 L2TP tunnel, multiple real-time streams should be active between the 452 source and destination of an L2TP tunnel. The packet size of the 453 real-time streams has to be small in order to permit a good bandwidth 454 saving. 456 If the source and destination of the L2TP tunnel are the same as the 457 source and destination of the compressing protocol sessions, then the 458 source and destination must have multiple active real-time streams to 459 get any benefit from multiplexing. 461 Because of this limitation, TCMTF is mostly useful for applications 462 where many real-time sessions run between a pair of endpoints. The 463 number of simultaneous sessions required to reduce the header 464 overhead to the desired level depends on the size of the L2TP header. 465 A smaller L2TP header will result in fewer simultaneous sessions 466 being required to produce adequate bandwidth efficiencies. 468 2.4. Tunneling 470 L2TP tunnels should be used to tunnel the ECRTP payloads end to end. 471 L2TP includes methods for tunneling messages used in PPP session 472 establishment, such as NCP (Network Control Protocol). This allows 473 [IPCP-HC] to negotiate ECRTP compression/decompression parameters. 475 Other tunneling schemes, such as GRE [GRE] may also be used to 476 implement the tunneling layer of TCMTF. 478 2.5. Encapsulation Formats 480 The packet format for a packet compressed is: 482 +------------+-----------------------+ 483 | | | 484 | Compr | | 485 | Header | Data | 486 | | | 487 | | | 488 +------------+-----------------------+ 490 Figure 6 492 The packet format of a multiplexed PPP packet as defined by [PPP-MUX] 493 is: 495 +-------+---+------+-------+-----+ +---+------+-------+-----+ 496 | Mux |P L| | | | |P L| | | | 497 | PPP |F X|Len1 | PPP | | |F X|LenN | PPP | | 498 | Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN| 499 | Field | | Field1| | | |FieldN | | 500 | (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | | 501 +-------+----------+-------+-----+ +----------+-------+-----+ 503 Figure 7 505 The combined format used for TCMTF with a single payload is all of 506 the above packets concatenated. Here is an example with one payload: 508 +------+------+-------+----------+-------+--------+----+ 509 | IP |Tunnel| Mux |P L| | | | | 510 |header|header| PPP |F X|Len1 | PPP | Compr | | 511 | (20) | | Proto |F T| | Proto | header |Data| 512 | | | Field | | Field1| | | 513 | | | (1) |1-2 octets| (0-2) | | | 514 +------+------+-------+----------+-------+--------+----+ 515 |<------------- IP payload -------------------->| 516 |<-------- Mux payload --------->| 518 Figure 8 520 If the tunnel contains multiplexed traffic, multiple "PPPMux 521 payload"s are transmitted in one IP packet. 523 3. Contributing Authors 525 Gonzalo Camarillo 526 Ericsson 527 Advanced Signalling Research Lab. 528 FIN-02420 Jorvas 529 Finland 531 Email: Gonzalo.Camarillo@ericsson.com 533 Michael A. Ramalho 534 Cisco Systems, Inc. 535 1802 Rue de la Porte 536 Wall Township, NJ 07719-3784 537 US 539 Phone: +1.732.449.5762 540 Email: mramalho@cisco.com 542 4. Acknowledgements 544 5. IANA Considerations 546 This memo includes no request to IANA. 548 6. Security Considerations 550 All drafts are required to have a security considerations section. 551 See RFC 3552 [RFC3552] for a guide. 553 7. References 555 7.1. Normative References 557 [ECRTP] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 558 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 559 High Delay, Packet Loss and Reordering", RFC 3545, 2003. 561 [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, 562 2005. 564 [FLV] ISO/IEC, "FLV and F4V File Format Specification", 565 14496-12 MPEG-4 Part 12, 2008. 567 [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 568 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 569 2000. 571 [I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 572 AAL", I. 363.2, 1997. 574 [IPCP-HC] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP 575 Header Compression over PPP", RFC 3544, 2003. 577 [IPHC] Degermark, M., Nordgren, B., and S. Pink, "IP Header 578 Compression", RFC 2580, 1999. 580 [L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 581 Protocol - Version 3 (L2TPv3)", RFC 3931, 2005. 583 [PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", 584 RFC 1661, 1994. 586 [PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", 587 RFC 3153, 2001. 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, March 1997. 592 [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 593 Header Compression (ROHC) Framework", RFC 4995, 2007. 595 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 596 Jacobson, "RTP: A Transport Protocol for Real-Time 597 Applications", RFC 3550, 2003. 599 [SCTP] Stewart, Ed., R., "Stream Control Transmission Protocol", 600 RFC 4960, 2007. 602 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., and et. 603 al., "SIP: Session Initiation Protocol", RFC 3261, 2005. 605 [TCRTP] Thomson, B., Koren, T., and D. Wing, "Tunneling 606 Multiplexed Compressed RTP (TCRTP)", RFC 4170, 2005. 608 [cRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 609 Headers for Low-Speed Serial Links", RFC 2508, 1999. 611 7.2. Informative References 613 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 614 Text on Security Considerations", BCP 72, RFC 3552, 615 July 2003. 617 Authors' Addresses 619 Jose Saldana 620 University of Zaragoza 621 Dpt. IEC Ada Byron Building 622 Zaragoza, 50018 623 Spain 625 Phone: +34 976 762 698 626 Email: jsaldana@unizar.es 628 Dan Wing 629 Cisco Systems 630 771 Alder Drive 631 San Jose, CA 95035 632 US 634 Phone: +44 7889 488 335 635 Email: dwing@cisco.com 637 Julian Fernandez Navajas 638 University of Zaragoza 639 Dpt. IEC Ada Byron Building 640 Zaragoza, 50018 641 Spain 643 Phone: +34 976 761 963 644 Email: navajas@unizar.es 646 Muthu Arul Mozhi Perumal 647 Cisco Systems 648 Cessna Business Park 649 Sarjapur-Marathahalli Outer Ring Road 650 Bangalore, Karnataka 560103 651 India 653 Phone: +91 9449288768 654 Email: mperumal@cisco.com 655 Jose 656 University of Zaragoza 657 Dpt. IEC Ada Byron Building 658 Zaragoza, 50018 659 Spain 661 Phone: +34 976762158 662 Email: jruiz@unizar.es