idnits 2.17.1 draft-saldana-tsvwg-tcmtf-05.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 11, 2013) is 3935 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 4960 (ref. 'SCTP') (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 2 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: Best Current Practice Cisco Systems 5 Expires: January 12, 2014 J. Fernandez Navajas 6 University of Zaragoza 7 Muthu. Perumal 8 Cisco Systems 9 F. Pascual Blanco 10 Telefonica I+D 11 July 11, 2013 13 Tunneling Compressed Multiplexed Traffic Flows (TCM-TF) 14 draft-saldana-tsvwg-tcmtf-05 16 Abstract 18 Tunneling Compressed and Multiplexed Traffic Flows (TCM-TF) is a 19 method for improving the bandwidth utilization of network segments 20 that carry multiple flows in parallel sharing a common path. The 21 method combines standard protocols for header compression, 22 multiplexing, and tunneling over a network path for the purpose of 23 reducing the bandwidth used when multiple flows are carried over that 24 path. The amount of packets per second can also be reduced. 26 This document describes the TCM-TF framework and the different 27 options which can be used for each layer (header compression, 28 multiplexing and tunneling). 30 Status of This Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 12, 2014. 47 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 1.2. Bandwidth efficiency of flows sending small packets . . . 3 64 1.2.1. Real-time applications using RTP . . . . . . . . . . 3 65 1.2.2. Real-time applications not using RTP . . . . . . . . 4 66 1.2.3. Other applications generating small packets . . . . . 4 67 1.2.4. Optimization of small-packet flows . . . . . . . . . 5 68 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.4. Scenarios of application . . . . . . . . . . . . . . . . 6 70 1.4.1. Residential scenario . . . . . . . . . . . . . . . . 6 71 1.4.2. Corporate environments . . . . . . . . . . . . . . . 7 72 1.4.3. Machine to Machine (M2M) scenario . . . . . . . . . . 8 73 1.5. Potential beneficiaries of TCM optimization . . . . . . . 9 74 1.6. Current Standard . . . . . . . . . . . . . . . . . . . . 9 75 1.7. Improved Standard Proposal . . . . . . . . . . . . . . . 10 76 2. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 11 77 2.1. Models of implementation . . . . . . . . . . . . . . . . 11 78 2.2. Choice of the compressing protocol . . . . . . . . . . . 12 79 2.2.1. Context Synchronization in ECRTP . . . . . . . . . . 13 80 2.2.2. Context Synchronization in ROHC . . . . . . . . . . . 14 81 2.3. Multiplexing . . . . . . . . . . . . . . . . . . . . . . 14 82 2.4. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 15 83 2.4.1. Tunneling schemes over IP: L2TP and GRE . . . . . . . 15 84 2.4.2. MPLS tunneling . . . . . . . . . . . . . . . . . . . 15 85 2.5. Encapsulation Formats . . . . . . . . . . . . . . . . . . 15 86 3. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17 87 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 7. Normative References . . . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 94 This document describes a way to combine existing protocols for 95 header compression, multiplexing and tunneling to save bandwidth for 96 applications that generate long-term flows of small packets. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 1.2. Bandwidth efficiency of flows sending small packets 106 The interactivity demands of some real-time services (VoIP, 107 videoconferencing, telemedicine, video vigilance, online gaming, 108 etc.) require a traffic profile consisting of high rates of small 109 packets, which are necessary in order to transmit frequent updates 110 between the two extremes of the communication. These services also 111 demand small network delays. In addition, some other services also 112 use small packets, although they are not delay-sensitive (e.g., 113 instant messaging, M2M packets sending collected data in sensor 114 networks using wireless or satellite scenarios). For both the delay- 115 sensitive and delay-insensitive applications, their small data 116 payloads incur significant overhead. 118 When a number of flows based on small packets (small-packet flows) 119 share the same path, bandwidth can be saved by multiplexing packets 120 belonging to different flows. If a transmission queue has not 121 already been formed but multiplexing is desired, it is necessary to 122 add a multiplexing delay, which has to be maintained under some 123 threshold if the service presents tight delay requirements. 125 1.2.1. Real-time applications using RTP 127 The first design of the Internet did not include any mechanism 128 capable of guaranteeing an upper bound for delivery delay, taking 129 into account that the first deployed services were e-mail, file 130 transfer, etc., in which delay is not critical. RTP [RTP] was first 131 defined in 1996 in order to permit the delivery of real-time 132 contents. Nowadays, although there are a variety of protocols used 133 for signaling real-time flows (SIP [SIP], H.323, etc.), RTP has 134 become the standard par excellence for the delivery of real-time 135 content. 137 RTP was designed to work over UDP datagrams. This implies that an 138 IPv4 packet carrying real-time information has to include 40 bytes of 139 headers: 20 for IPv4 header, 8 for UDP, and 12 for RTP. This 140 overhead is significant, taking into account that many real-time 141 services send very small payloads. It becomes even more significant 142 with IPv6 packets, as the basic IPv6 header is twice the size of the 143 IPv4 header. Table 1 illustrates the overhead problem of VoIP for 144 two different codecs. 146 +--------------------------------+----------------------------------+ 147 | IPv4 | IPv6 | 148 +--------------------------------+----------------------------------+ 149 | IPv4+UDP+RTP: 40 bytes header | IPv6+UDP+RTP: 60 bytes header | 150 | G.711 at 20 ms packetization: | G.711 at 20 ms packetization: | 151 | 25% header overhead | 37.5% header overhead | 152 | G.729 at 20 ms packetization: | G.729 at 20 ms packetization: | 153 | 200% header overhead | 300% header overhead | 154 +--------------------------------+----------------------------------+ 156 Table 1: Efficiency of different voice codecs 158 1.2.2. Real-time applications not using RTP 160 At the same time, there are many real-time applications that do not 161 use RTP. Some of them send UDP (but not RTP) packets, e.g., First 162 Person Shooter (FPS) online games, for which latency is very 163 critical. 165 There is also another kind of applications which have been reported 166 as real-time using TCP: MMORPGs (Massively Multiplayer Online Role 167 Playing Games), which in some cases have millions of players, 168 thousands of them sharing the same virtual world. They use TCP 169 packets to send the player commands to the server, and also to send 170 to the player's application the characteristics and situation of 171 other gamers' avatars. These games do not have the same 172 interactivity of FPSs, but the quickness and the movements of the 173 players are important, and can decide if they win or lose a fight. 175 Finally, there is also another fact which has to be taken into 176 account: TCP is getting used for media delivery. For many reasons, 177 such as avoiding firewalls, the standard RTP/UDP/IP protocol stack is 178 substituted in many cases by FLV/HTTP/TCP/IP (FLash Video [FLV]). 180 1.2.3. Other applications generating small packets 182 Other applications without delay constraints are also becoming 183 popular (e.g., instant messaging, M2M packets sending collected data 184 in sensor networks using wireless or satellite scenarios). The 185 number of wireless M2M (machine-to-machine) connections is steady 186 growing since a few years, and a share of these is being used for 187 delay-intolerant applications, e.g., industrial SCADA (Supervisory 188 Control And Data Acquisition), power plant monitoring, smart grids, 189 asset tracking. 191 1.2.4. Optimization of small-packet flows 193 In order to mitigate the bad network efficiency of flows using small 194 packets, the multiplexing of a number of payloads into a single 195 packet can be considered as a solution. For example, if a single 196 VoIP flow is considered, the number of samples included in a packet 197 can be increased, but at the cost of adding new packetization delays. 199 When a number of flows share the same path between an origin and a 200 destination, a multiplexer can build a bigger packet in which a 201 number of payloads share a common header. A demultiplexer is 202 necessary at the end of the common path, so as to rebuild the packets 203 as they were originally sent, making multiplexing a transparent 204 process for the extremes of the flow. 206 In addition, the headers of the original packets can be compressed to 207 save more bandwidth, using some of the already existing header 208 compression standards ([cRTP], [ECRTP], [IPHC], [ROHC]). When 209 different headers are compressed together, tunneling can be used to 210 relieve intermediate routers from the decompression and compression 211 processing. 213 If only one stream is tunneled and compressed, then little bandwidth 214 savings will be obtained. In contrast, multiplexing is helpful to 215 amortize the overhead of the tunnel header over many payloads. The 216 obtained savings grow with the number of flows optimized together. 218 1.3. Terminology 220 This document uses a number of terms to refer to the roles played by 221 the entities using TCM-TF. 223 o native packet 225 A packet sent by an application, belonging to a flow that can be 226 optimized by means of TCM-TF. 228 o native flow 230 A flow of native packets. It can be considered a "small-packet flow" 231 when the vast majority of the generated packets present a low 232 payload-to-header ratio. 234 o TCM packet 236 A packet including a number of multiplexed and header-compressed 237 native ones, and also a tunneling header. 239 o TCM flow 241 A flow of TCM packets, including a number of optimized native flows. 243 o TCM optimizer 245 The host where TCM optimization is deployed. It corresponds to both 246 the ingress and the egress of the tunnel transporting the compressed 247 and multiplexed packets. 249 If the optimizer compresses headers, multiplexes packets and creates 250 the tunnel, it behaves as a "TCM-ingress optimizer", or "TCM-IO". It 251 takes native packets or flows and "optimizes" them. 253 If it extracts packets from the tunnel, demultiplexes packets and 254 decompresses headers, it behaves as a "TCM-egress optimizer", or 255 "TCM-EO". The TCM-egress optimizer takes a TCM flow and "rebuilds" 256 the native packets as they were originally sent. 258 o TCM-TF session 260 The relationship between a pair of TCM optimizers exchanging TCM 261 packets. 263 o policy manager 265 A network entity which makes the decisions about TCM-TF parameters: 266 multiplexing period to be used, flows to be optimized together, 267 depending on their IP addresses, ports, etc. It is connected with a 268 number of TCM-TF optimizers, and orchestrates the optimization that 269 takes place between them. 271 1.4. Scenarios of application 273 Different scenarios of application can be considered for the 274 tunneling, compressing and multiplexing solution: 276 1.4.1. Residential scenario 278 If we consider the residential users of a real-time interactive 279 application (e.g., VoIP, an online game generating small packets) in 280 a town or a district, a TCM optimizing module can be included in 281 network devices, in order to group packets with the same destination. 282 Depending on the number of users of the application, the packets 283 could be grouped at different levels in DSL fixed network scenarios, 284 at gateway level in LTE mobile network scenarios or even in other ISP 285 edge routers. TCM-TF may also be applied for fiber residential 286 accesses, and in 2G/3G mobile networks. This would reduce bandwidth 287 requirements in the provider aggregation network, and in the network 288 connection of the application provider, thus resulting in savings for 289 both actors. 291 In this scenario, agreements between different companies can be 292 established in order to save bandwidth and to reduce packets per 293 second. For example, a service provider (e.g., an online gaming 294 company) could be allowed to place a TCM optimizer in the aggregation 295 network of an ISP, being able to optimize all the flows of a game or 296 service. Another TCM optimizer would rebuild these packets once they 297 arrive to the network of the provider. 299 At the same time, the ISP would implement TCM-TF capabilities within 300 its own MPLS network in order to optimize internal network resources: 301 optimizing modules could be embedded in the Label Edge Routers of the 302 network. In that scenario MPLS would be the "tunneling" layer, being 303 the tunnels the paths defined by the MPLS labels and avoiding the use 304 of other tunneling protocols. 306 Finally, some networks use cRTP [cRTP] on their access links. This 307 gives bandwidth savings on the access link, but as a counterpart it 308 consumes considerable CPU resources on the aggregation router. In 309 these cases, by means of TCM, instead of only saving bandwidth on the 310 access link, it could also be saved across the core, and on the far- 311 end access link, all without the CPU impact on the aggregation 312 router. 314 1.4.2. Corporate environments 316 End users can also optimize traffic end-to-end from network borders. 317 As an example, we can consider the case of an enterprise with a 318 number of distributed central offices, in which an appliance could be 319 placed next to the access router, being able to optimize traffic 320 flows with a shared origin and destination. Thus, a number of remote 321 desktop sessions to the same server could be optimized, or a number 322 of VoIP calls between two offices could also require less bandwidth 323 and fewer packets per second. 325 Another example of an end user collaborating in traffic optimization 326 could be an Internet cafe, which is suitable of having many users of 327 the same application (e.g., a game) sharing the same access link. 328 Internet cafes are very popular in countries with relatively low 329 access speeds in households, where home computer penetration is 330 usually low as well. In many of these countries, bandwidth can 331 become a serious limitation for this kind of business, so TCM-TF 332 savings may become critical for their viability. 334 Satellite communication links that often manage the bandwidth by 335 limiting the transmission rate, measured in packets per second (pps), 336 to and from the satellite. Applications like VoIP that generate a 337 large number of small packets can easily fill the maximum number of 338 pps slots, limiting the throughput across such links. As an example, 339 a G.729a voice call generates 50 pps at 20 ms packetization time. If 340 the satellite transmission allows 1,500 pps, the number of 341 simultaneous voice calls is limited to 30. This results in poor 342 utilization of the satellite link's bandwidth as well as places a low 343 bound on the number of voice calls that can utilize the link 344 simultaneously. TCM optimization of small packets into one packet 345 for transmission would improve the efficiency. Satellite links would 346 also find it useful to multiplex and compress small TCP packets into 347 one packet. This could be especially interesting for compressing TCP 348 ACKs. 350 Desktop or application sharing where the traffic from the server to 351 the client typically consists of the delta of screen updates. Also, 352 the standard for remote desktop sharing emerging for WebRTC in the 353 RTCWEB Working Group is: {something}/SCTP/UDP (Stream Control 354 Transmission Protocol [SCTP]). In this scenario, SCTP/UDP could be 355 used in other cases: chatting, file sharing and applications related 356 to WebRTC peers. There could be hundreds of clients at a site 357 talking to a server located at a datacenter over a WAN. Compressing, 358 multiplexing and tunneling this traffic could save WAN bandwidth and 359 potentially improve latency. 361 1.4.3. Machine to Machine (M2M) scenario 363 In a M2M/SCADA (Supervisory Control And Data Acquisition) context, 364 TCM optimization can be applied when a satellite link is used for 365 collecting the data of a number of sensors. M2M terminals are 366 normally equipped with sensing devices which can interface to 367 proximity sensor networks through wireless connections. The terminal 368 can send the collected sensing data using a satellite link connecting 369 to a satellite gateway, which in turn will forward the M2M/SCADA data 370 to the to the processing and control center through Internet. The 371 size of typical M2M application transaction depends on the specific 372 service and it may vary from a minimum of 20 bytes (e.g., tracking 373 and metering in private security) to about 1,000 bytes (e.g., video- 374 surveillance). In this context, TCM-TF concepts can be also applied 375 to allow a more efficient use of the available satellite link 376 capacity, matching the requirements demanded by some M2M services. 377 If the case of large sensor deployments is considered, where 378 proximity sensor networks transmit data through different satellite 379 terminals, the use of compression algorithms already available in 380 current satellite systems to reduce the overhead introduced by TCP or 381 UDP and IPv6 protocols is certainly desirable. In addition to this, 382 tunneling and multiplexing functions available from TCM-TF allows 383 extending compression functionality throughout the rest the network, 384 to eventually reach the processing and control centers. 386 1.5. Potential beneficiaries of TCM optimization 388 In conclusion, a standard able to compress headers, multiplex a 389 number of packets and send them together using a tunnel, can benefit 390 various stakeholders: 392 o network operators can compress traffic flows sharing a common 393 network segment; 395 o ISPs; 397 o developers of VoIP systems can include this option in their 398 solutions; 400 o service providers, who can achieve bandwidth savings in their 401 supporting infrastructures. 403 Other fact that has to be taken into account is that the technique 404 not only saves bandwidth but also reduces the number of packets per 405 second, which sometimes can be a bottleneck for a satellite link or 406 even for a network router. 408 1.6. Current Standard 410 The current standard [TCRTP] defines a way to reduce bandwidth and 411 pps of RTP traffic, by combining three different standard protocols: 413 o Regarding compression, [ECRTP] is the selected option. 415 o Multiplexing is accomplished using PPP Multiplexing [PPP-MUX] 417 o Tunneling is accomplished by using L2TP (Layer 2 Tunneling 418 Protocol [L2TPv3]). 420 The three layers are combined as shown in the Figure 1: 422 RTP/UDP/IP 423 | 424 | ---------------------------- 425 | 426 ECRTP compressing layer 427 | 428 | ---------------------------- 429 | 430 PPPMUX multiplexing layer 431 | 432 | ---------------------------- 433 | 434 L2TP tunneling layer 435 | 436 | ---------------------------- 437 | 438 IP 440 Figure 1 442 1.7. Improved Standard Proposal 444 In contrast to the current standard [TCRTP], TCM-TF allows other 445 header compression protocols in addition to RTP/UDP, since services 446 based on small packets also use by bare UDP or TCP, as shown in 447 Figure 2: 449 TCP/IP UDP/IP RTP/UDP/IP 450 \ | / 451 \ | / ------------------------------ 452 \ | / 453 Nothing or ROHC or ECRTP or IPHC header compressing layer 454 | 455 | ------------------------------ 456 | 457 PPPMUX or other mux protocols multiplexing layer 458 | 459 / \ ------------------------------ 460 / \ 461 / \ 462 GRE or L2TP \ tunneling layer 463 | MPLS 464 | ------------------------------ 465 IP 467 Figure 2 469 Each of the three layers is considered as independent of the other 470 two, i.e. different combinations of protocols can be implemented 471 according to the new proposal: 473 o Regarding compression, a number of options can be considered: as 474 different standards are able to compress different headers 475 ([cRTP], [ECRTP], [IPHC], [ROHC]). The one to be used could be 476 selected depending on the traffic to compress and the concrete 477 scenario (packet loss percentage, delay, etc.). It also exists 478 the possibility of having a null header compression, in the case 479 of wanting to avoid traffic compression, taking into account the 480 need of storing a context for every flow and the problems of 481 context desynchronization in certain scenarios. Although non 482 shown in Figure 2, ESP (Encapsulating Security Payload [ESP]) 483 headers can also be compressed. 485 o Multiplexing is also accomplished using PPP Multiplexing 486 [PPP-MUX]. Nevertheless, other multiplexing protocols can also be 487 considered. 489 o Tunneling is accomplished by using L2TP (Layer 2 Tunneling 490 Protocol [L2TPv3]) over IP, GRE (Generic Routing Encapsulation 491 [GRE]) over IP, or MPLS (Multiprotocol Label Switching 492 Architecture [MPLS]). 494 It can be observed that TCRTP [TCRTP] is included as an option in 495 TCM-TF, combining [ECRTP], [PPP-MUX] and [L2TPv3]. 497 Payload compression schemes could also be used, but they are not the 498 aim of this document. 500 2. Protocol Operation 502 This section describes how to combine protocols belonging to trhee 503 layers (compressing, multiplexing, and tunneling), in order to save 504 bandwidth for the considered flows. 506 2.1. Models of implementation 508 TCM-TF can be implemented in different ways. The most 509 straightforward is to implement it in the devices terminating the 510 flows (these devices can be e.g., voice gateways, or proxies grouping 511 a number of flows): 513 [ending device]---[ending device] 514 ^ 515 | 516 TCM-TF over IP 518 Figure 3 520 Another way TCM-TF can be implemented is with an external 521 concentration device. This device could be placed at strategic 522 places in the network and could dynamically create and destroy TCM-TF 523 sessions without the participation of the endpoints that generate the 524 flows (Figure 4). 526 [ending device]\ /[ending device] 527 [ending device]---[concentrator]---[concentrator]---[ending device] 528 [ending device]/ \[ending device] 529 ^ ^ ^ 530 | | | 531 Native IP TCM-TF over IP Native IP 533 Figure 4 535 A number of already compressed flows can also be merged in a tunnel 536 using a concentrator in order to increase the number of flows in a 537 tunnel (Figure 5): 539 [ending device]\ /[ending device] 540 [ending device]---[concentrator]---[concentrator]---[ending device] 541 [ending device]/ \[ending device] 542 ^ ^ ^ 543 | | | 544 Compressed TCM-TF over IP Compressed 546 Figure 5 548 2.2. Choice of the compressing protocol 550 There are different protocols that can be used for compressing IP 551 flows: 553 o IPHC (IP Header Compression [IPHC]) permits the compression of TCP 554 /IP, UDP/IP and ESP/IP headers. It has a low implementation 555 complexity. On the other hand, the resynchronization of the 556 context can be slow over long RTT links. It should be used in 557 scenarios presenting very low packet loss percentage. 559 o cRTP (compressed RTP [cRTP]) works the same way as IPHC, but is 560 also able to compress RTP headers. The link layer transport is 561 not specified, but typically PPP is used. For cRTP to compress 562 headers, it must be implemented on each PPP link. A lot of 563 context is required to successfully run cRTP, and memory and 564 processing requirements are high, especially if multiple hops must 565 implement cRTP to save bandwidth on each of the hops. At higher 566 line rates, cRTP's processor consumption becomes prohibitively 567 expensive. cRTP is not suitable over long-delay WAN links commonly 568 used when tunneling, as proposed by this document. To avoid the 569 per-hop expense of cRTP, a simplistic solution is to use cRTP with 570 L2TP to achieve end-to-end cRTP. However, cRTP is only suitable 571 for links with low delay and low loss. Thus, if multiple router 572 hops are involved, cRTP's expectation of low delay and low loss 573 can no longer be met. Furthermore, packets can arrive out of 574 order. 576 o ECRTP (Enhanced Compressed RTP [ECRTP]) is an extension of cRTP 577 [cRTP] that provides tolerance to packet loss and packet 578 reordering between compressor and decompressor. Thus, ECRTP 579 should be used instead of cRTP when possible (e.g., the two TCM 580 optimizers implementing ECRTP). 582 o ROHC (RObust Header Compression [ROHC]) is able to compress TCP/ 583 IP, UDP/IP, ESP/IP and RTP/UDP/IP headers. It is a robust scheme 584 developed for header compression over links with high bit error 585 rate, such as wireless ones. It incorporates mechanisms for quick 586 resynchronization of the context. It includes an improved 587 encoding scheme for compressing the header fields that change 588 dynamically. Its main drawback is that it requires significantly 589 more processing and memory resources than the ones necessary for 590 IPHC or ECRTP. 592 This standard does not determine which of the existing protocols has 593 to be used for the compressing layer. The decision will depend on 594 the scenario, and will mainly be determined by the packet loss 595 probability, RTT, and the availability of memory and processing 596 resources. The standard is also suitable to include other 597 compressing schemes that may be further developed. 599 2.2.1. Context Synchronization in ECRTP 601 When the compressor receives an RTP packet that has an unpredicted 602 change in the RTP header, the compressor should send a COMPRESSED_UDP 603 packet (described in [ECRTP]) to synchronize the ECRTP decompressor 604 state. The COMPRESSED_UDP packet updates the RTP context in the 605 decompressor. 607 To ensure delivery of updates of context variables, COMPRESSED_UDP 608 packets should be delivered using the robust operation described in 609 [ECRTP]. 611 Because the "twice" algorithm described in [ECRTP] relies on UDP 612 checksums, the IP stack on the RTP transmitter should transmit UDP 613 checksums. If UDP checksums are not used, the ECRTP compressor 614 should use the cRTP Header checksum described in [ECRTP]. 616 2.2.2. Context Synchronization in ROHC 618 ROHC [ROHC] includes a more complex mechanism in order to maintain 619 context synchronization. It has different operation modes and 620 defines compressor states which change depending on link behavior. 622 2.3. Multiplexing 624 Header compressing algorithms require a layer two protocol that 625 allows identifying different protocols. PPP [PPP] is suited for 626 this, although other multiplexing protocols can also be used for this 627 layer of TCM-TF. 629 When header compression is used inside a tunnel, it reduces the size 630 of the headers of the IP packets carried in the tunnel. However, the 631 tunnel itself has overhead due to its IP header and the tunnel header 632 (the information necessary to identify the tunneled payload). 634 By multiplexing multiple small payloads in a single tunneled packet, 635 reasonable bandwidth efficiency can be achieved, since the tunnel 636 overhead is shared by multiple packets belonging to the flows active 637 between the source and destination of an L2TP tunnel. The packet 638 size of the flows has to be small in order to permit good bandwidth 639 savings. 641 If the source and destination of the tunnel are the same as the 642 source and destination of the compressing protocol sessions, then the 643 source and destination must have multiple active small-packet flows 644 to get any benefit from multiplexing. 646 Because of this, TCM-TF is mostly useful for applications where many 647 small-packet flows run between a pair of hosts. The number of 648 simultaneous sessions required to reduce the header overhead to the 649 desired level depends on the average payload size, and also on the 650 size of the tunnel header. A smaller tunnel header will result in 651 fewer simultaneous sessions being required to produce adequate 652 bandwidth efficiencies. 654 2.4. Tunneling 656 Different tunneling schemes can be used for sending end to end the 657 compressed payloads. 659 2.4.1. Tunneling schemes over IP: L2TP and GRE 661 L2TP tunnels should be used to tunnel the compressed payloads end to 662 end. L2TP includes methods for tunneling messages used in PPP 663 session establishment, such as NCP (Network Control Protocol). This 664 allows [IPCP-HC] to negotiate ECRTP compression/decompression 665 parameters. 667 Other tunneling schemes, such as GRE [GRE] may also be used to 668 implement the tunneling layer of TCM-TF. 670 2.4.2. MPLS tunneling 672 In some scenarios, mainly in operator's core networks, the use of 673 MPLS is widely deployed as data transport method. The adoption of 674 MPLS as tunneling layer in this proposal intends to natively adapt 675 TCM-TF to those transport networks. 677 In the same way that layer 3 tunnels, MPLS paths, identified by MPLS 678 labels, established between Label Edge Routers (LSRs), could be used 679 to transport the compressed payloads within an MPLS network. This 680 way, multiplexing layer must be placed over MPLS layer. Note that, 681 in this case, layer 3 tunnel headers do not have to be used, with the 682 consequent data efficiency improvement. 684 2.5. Encapsulation Formats 686 The packet format for a packet compressed is: 688 +------------+-----------------------+ 689 | | | 690 | Compr | | 691 | Header | Data | 692 | | | 693 | | | 694 +------------+-----------------------+ 696 Figure 6 698 The packet format of a multiplexed PPP packet as defined by [PPP-MUX] 699 is: 701 +-------+---+------+-------+-----+ +---+------+-------+-----+ 702 | Mux |P L| | | | |P L| | | | 703 | PPP |F X|Len1 | PPP | | |F X|LenN | PPP | | 704 | Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN| 705 | Field | | Field1| | | |FieldN | | 706 | (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | | 707 +-------+----------+-------+-----+ +----------+-------+-----+ 709 Figure 7 711 The combined format used for TCM-TF with a single payload is all of 712 the above packets concatenated. Here is an example with one payload, 713 using L2TP or GRE tunneling: 715 +------+------+-------+----------+-------+--------+----+ 716 | IP |Tunnel| Mux |P L| | | | | 717 |header|header| PPP |F X|Len1 | PPP | Compr | | 718 | (20) | | Proto |F T| | Proto | header |Data| 719 | | | Field | | Field1| | | 720 | | | (1) |1-2 octets| (0-2) | | | 721 +------+------+-------+----------+-------+--------+----+ 722 |<------------- IP payload -------------------->| 723 |<-------- Mux payload --------->| 725 Figure 8 727 If the tunneling technology is MPLS, then the scheme would be: 729 +------+-------+----------+-------+--------+----+ 730 |MPLS | Mux |P L| | | | | 731 |header| PPP |F X|Len1 | PPP | Compr | | 732 | | Proto |F T| | Proto | header |Data| 733 | | Field | | Field1| | | 734 | | (1) |1-2 octets| (0-2) | | | 735 -+------+-------+----------+-------+--------+----+ 736 |<---------- MPLS payload -------------->| 737 |<-------- Mux payload --------->| 739 Figure 9 741 If the tunnel contains multiplexed traffic, multiple "PPPMux 742 payload"s are transmitted in one IP packet. 744 3. Contributing Authors 746 Gonzalo Camarillo 747 Ericsson 748 Advanced Signalling Research Lab. 749 FIN-02420 Jorvas 750 Finland 752 Email: Gonzalo.Camarillo@ericsson.com 754 Michael A. Ramalho 755 Cisco Systems, Inc. 756 8000 Hawkins Road 757 Sarasota, FL 34241-9300 758 US 760 Phone: +1.732.832.9723 761 Email: mramalho@cisco.com 763 Jose Ruiz Mas 764 University of Zaragoza 765 Dpt. IEC Ada Byron Building 766 50018 Zaragoza 767 Spain 769 Phone: +34 976762158 770 Email: jruiz@unizar.es 772 Diego Lopez Garcia 773 Telefonica I+D 774 Ramon de la cruz 84 775 28006 Madrid 776 Spain 778 Phone: +34 913129041 779 Email: diego@tid.es 781 David Florez Rodriguez 782 Telefonica I+D 783 Ramon de la cruz 84 784 28006 Madrid 785 Spain 787 Phone: +34 91312884 788 Email: dflorez@tid.es 790 Manuel Nunez Sanz 791 Telefonica I+D 792 Ramon de la cruz 84 793 28006 Madrid 794 Spain 796 Phone: +34 913128821 797 Email: mns@tid.es 799 Juan Antonio Castell Lucia 800 Telefonica I+D 801 Ramon de la cruz 84 802 28006 Madrid 803 Spain 805 Phone: +34 913129157 806 Email: jacl@tid.es 808 Mirko Suznjevic 809 University of Zagreb 810 Faculty of Electrical Engineering and Computing, Unska 3 811 10000 Zagreb 812 Croatia 814 Phone: +385 1 6129 755 815 Email: mirko.suznjevic@fer.hr 817 4. Acknowledgements 819 5. IANA Considerations 821 This memo includes no request to IANA. 823 6. Security Considerations 825 The most straightforward option for securing a number of non-secured 826 flows sharing a path is by the use of IPsec [IPsec], when TCM using 827 an IP tunnel is employed. Instead of adding a security header to the 828 packets of each native flow, and then compressing and multiplexing 829 them, a single IPsec tunnel can be used in order to secure all the 830 flows together, thus achieving a higher efficiency. This use of 831 IPsec protects the packets only within the transport network between 832 tunnel ingress and egress and therefore does not provide end-to-end 833 authentication or encryption. In some cases , e.g., where the end 834 points are trusted, this model may be appropriate. 836 When a number of already secured flows including ESP [ESP] headers 837 are optimized by means of TCM, and the addition of further security 838 is not necessary, their ESP/IP headers can still be compressed using 839 suitable algorithms [RFC5225], in order to improve the efficiency. 840 This header compression does not change the end-to-end security 841 model. 843 Future versions of this document will consider whether some TCM-TF 844 mechanisms could be potentially exploited in order to deploy or 845 amplify DoS attacks against network infrastructure. Solutions will 846 be provided if potential attacks are identified. 848 7. Normative References 850 [ECRTP] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 851 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 852 High Delay, Packet Loss and Reordering", RFC 3545, 2003. 854 [ESP] Kent, S., "IP Encapsulating Security Payload ", RFC 4303, 855 2005. 857 [FLV] ISO/IEC, "FLV and F4V File Format Specification", 14496-12 858 MPEG-4 Part 12, 2008. 860 [GRE] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 861 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 862 2000. 864 [I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 865 AAL", I. 363.2, 1997. 867 [IPCP-HC] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP 868 Header Compression over PPP", RFC 3544, 2003. 870 [IPHC] Degermark, M., Nordgren, B., and S. Pink, "IP Header 871 Compression", RFC 2580, 1999. 873 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 874 Internet Protocol", RFC 4301, December 2005. 876 [L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 877 Protocol - Version 3 (L2TPv3)", RFC 3931, 2005. 879 [MPLS] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 880 Label Switching Architecture", RFC 3031, January 2001. 882 [PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", 883 RFC 3153, 2001. 885 [PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 886 1661, 1994. 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, March 1997. 891 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 892 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 893 UDP-Lite ", RFC 5225, April 2008. 895 [ROHC] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 896 Header Compression (ROHC) Framework", RFC 5795, 2010. 898 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 899 Jacobson, "RTP: A Transport Protocol for Real-Time 900 Applications", RFC 3550, 2003. 902 [SCTP] Stewart, Ed., R., "Stream Control Transmission Protocol", 903 RFC 4960, 2007. 905 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., and et. 906 al., "SIP: Session Initiation Protocol", RFC 3261, 2005. 908 [TCRTP] Thomson, B., Koren, T., and D. Wing, "Tunneling 909 Multiplexed Compressed RTP (TCRTP)", RFC 4170, 2005. 911 [cRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 912 Headers for Low-Speed Serial Links", RFC 2508, 1999. 914 Authors' Addresses 916 Jose Saldana 917 University of Zaragoza 918 Dpt. IEC Ada Byron Building 919 Zaragoza 50018 920 Spain 922 Phone: +34 976 762 698 923 Email: jsaldana@unizar.es 924 Dan Wing 925 Cisco Systems 926 771 Alder Drive 927 San Jose, CA 95035 928 US 930 Phone: +44 7889 488 335 931 Email: dwing@cisco.com 933 Julian Fernandez Navajas 934 University of Zaragoza 935 Dpt. IEC Ada Byron Building 936 Zaragoza 50018 937 Spain 939 Phone: +34 976 761 963 940 Email: navajas@unizar.es 942 Muthu Arul Mozhi Perumal 943 Cisco Systems 944 Cessna Business Park 945 Sarjapur-Marathahalli Outer Ring Road 946 Bangalore, Karnataka 560103 947 India 949 Phone: +91 9449288768 950 Email: mperumal@cisco.com 952 Fernando Pascual Blanco 953 Telefonica I+D 954 Ramon de la Cruz 84 955 Madrid 28006 956 Spain 958 Phone: +34 913128779 959 Email: fpb@tid.es