idnits 2.17.1 draft-saldana-tsvwg-simplemux-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2019) is 1880 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Chabarek' is defined on line 638, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1692 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group J. Saldana 3 Internet-Draft J. Fernandez Navajas 4 Intended status: Standards Track J. Ruiz Mas 5 Expires: September 5, 2019 University of Zaragoza 6 March 4, 2019 8 Simplemux. A generic multiplexing protocol 9 draft-saldana-tsvwg-simplemux-11 11 Abstract 13 The high amount of small packets present in nowaday's networks 14 results in a low efficiency, as the size of the headers and the 15 payload of these packets can be in the same order of magnitude. In 16 some situations, multiplexing (i.e. aggregating) a number of small 17 packets into a bigger one is desirable in order to improve the 18 efficiency. For example, a number of small packets can be sent 19 together between a pair of machines if they share a common network 20 path. This may happen between machines in different locations or 21 even inside a datacenter with a number of servers hosting virtual 22 machines. Thus, the traffic profile can be shifted from small to 23 larger packets, reducing the network overhead and the number of 24 packets per second to be managed by intermediate routers. 26 This document describes Simplemux, a protocol able to encapsulate a 27 number of packets belonging to different protocols into a single 28 packet. Small headers (separators) are added at the beginning of 29 each multiplexed packet, including some flags, the packet length and 30 a "Protocol" field. This allows the inclusion of a number of packets 31 belonging to different protocols (the "multiplexed packets") on a 32 packet of another protocol (the "tunneling protocol"). 34 In order to reduce the overhead, the size of the multiplexing headers 35 is kept very low (it may be a single byte when multiplexing packets 36 of small size). 38 Status of This Memo 40 This Internet-Draft is submitted to IETF in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on September 5, 2019. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 71 1.2. Existing multiplexing protocols . . . . . . . . . . . . . 4 72 1.3. Benefits of multiplexing . . . . . . . . . . . . . . . . 5 73 2. Description of the scenario . . . . . . . . . . . . . . . . . 6 74 3. Protocol description . . . . . . . . . . . . . . . . . . . . 6 75 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 7.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 The high amount of small packets present in nowaday's networks 86 results in a low efficiency, when the size of the headers and the 87 payload are in the same order of magnitude. In some situations, 88 multiplexing (i.e. aggragating) a number of small packets into a 89 bigger one is desirable in order to improve the efficiency. For 90 example, a number of small packets can be sent together between a 91 pair of machines if they share a common network path. This may 92 happen between machines in different locations or even inside a 93 datacenter with a number of servers hosting virtual machines. Thus, 94 the traffic profile can be shifted from small to larger packets, thus 95 reducing the network overhead and the number of packets per second to 96 be managed by intermediate routers. 98 This document describes Simplemux, a protocol able to encapsulate a 99 number of packets belonging to different protocols into a single 100 packet. This can be useful e.g. for grouping small packets and thus 101 reducing the number of packets per second in a network. 103 Simplemux is a generic multiplexing protocol, i.e. it can be used to 104 aggregate a number of packets belonging to a protocol, on a single 105 packet belonging to other (or the same) protocol. 107 In this document we will talk about the "multiplexed" protocol, and 108 the "tunneling" protocol, being Simplemux the "multiplexing" 109 protocol. The "external header" will be the one of the "tunneling" 110 protocol (see the figure (Figure 1)) 112 +--------------------------------+ 113 | Multiplexed Packet | Multiplexed protocol 114 +--------------------------------+ 115 | Simplemux | Multiplexing protocol 116 +--------------------------------+ 117 | Tunneling header | Tunneling protocol 118 +--------------------------------+ 120 Figure 1 122 As an example, if a number of small IPv6 packets have to travel over 123 an IPv4 network, they can be multiplexed and put into a single IPv4 124 packet. In this case, IPv4 is the "tunneling" protocol and IPv6 is 125 the "multiplexed" protocol. The IPv4 header is called in this case 126 the "tunneling" or the "external" header. The simplified scheme of 127 this packet would be: 129 |IPv4 hdr||Simplemux hdr|IPv6 packet||Simplemux hdr|IPv6 packet||...| 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 1.2. Existing multiplexing protocols 139 Different multiplexing protocols have been approved by the IETF in 140 the past: 142 o TMux [RFC1692] 144 TMux is able to combine multiple short transport segments, 145 independent of application type, and send them between a server and 146 host pair. As stated in the reference, "The TMux protocol is 147 intended to optimize the transmission of large numbers of small data 148 packets. In particular, communication load is not measured only in 149 bits per seconds but also in packets per seconds, and in many 150 situation the latter is the true performance limit, not the former. 151 The proposed multiplexing is aimed at alleviating this situation." 153 A TMux message appears as: 155 |IP hdr||TMux hdr|Transport segment||TMux hdr|Transport segment||...| 157 Therefore, the Transport Segment is not an entire IP packet, since it 158 does not include the IP header. 160 TMux works "between a server and host pair," so it multiplexes a 161 number of segments between the same pair of machines. However, there 162 are scenarios where a number of low-efficiency flows share a common 163 path, but they do not travel between the same pair of machines. 165 o PPPMux [RFC3153] 167 PPPMux "sends multiple PPP encapsulated packets in a single PPP 168 frame. As a result, the PPP overhead per packet is reduced." Thus, 169 it is able to multiplex complete IP packets, using separators. 171 However, the use of PPPMux requires the use of PPP and L2TP in order 172 to multiplex a number of packets together, as done in TCRTP 173 [RFC4170]. Thus, it introduces more overhead and complexity. 175 An IP packet including a number of them using PPPMux appears as: 177 |IP hdr|L2TP hdr|PPP hdr||PPPMux hdr|packet||PPPMux hdr|packet||...| 179 The scheme proposed by PPPMux is similar to the Compound-Frames of 180 PPP LCP Extensions [RFC1570]. The key differences are that PPPMux is 181 more efficient and that it allows concatenation of variable sized 182 frames. 184 *** 186 The definition of a protocol able to multiplex complete packets, 187 avoiding the need of other protocols as e.g. PPP is seen as 188 convenient. The multiplexed packets can be of any kind, since a 189 "Protocol Number" field can be added to each of them. Not all the 190 packets multiplexed together must belong to the same protocol. The 191 general scheme of Simplemux is: 193 |tunnel hdr||Simplemux hdr|packet||Simplemux hdr|packet||...| 195 The Simplemux header includes the "Protocol Number" field, so it 196 permits the multiplexing of different kinds of packets in the same 197 bundle. 199 In this document, we will also refer to the Simplemux header with the 200 terms "separator," "Simplemux separator" or "mux separator". In the 201 figures we will also use the abbreviation "Smux". 203 When applied to IP packets, the scheme of a multiplexed packet 204 becomes: 206 |tunnel hdr||Simplemux hdr|IP packet||Simplemux hdr|IP packet||...| 208 1.3. Benefits of multiplexing 210 The benefits of multiplexing are: 212 - Tunneling a number of packets together. If a number of packets 213 have to be tunneled through a network segment, they can be 214 multiplexed and then sent together using a single external header. 215 This will avoid the need for adding a tunneling header to each of the 216 packets, thus reducing the overhead. 218 - Reduction of the amount of packets per second in the network. It 219 is desirable for two main reasons: first, network equipment has a 220 limitation in terms of the number of packets per second it can 221 manage, i.e. many devices are not able to send small packets back to 222 back due to processing delay. 224 - Bandwidth reduction. The presence of high rates of tiny packets 225 translates into an inefficient usage of network resources, so there 226 is a need for mechanisms able to reduce the overhead introduced by 227 low-efficiency flows. When combined with header compression, as done 228 in TCRTP [RFC4170] multiplexing may produce significant bandwidth 229 savings, which are interesting for network operators, since they may 230 alleviate the traffic load in their networks. 232 - Energy savings: a lower amount of packets per second will reduce 233 energy consumption in network equipment since, according to [Bolla], 234 internal packet processing engines and switching fabric require 60% 235 and 18% of the power consumption of high-end routers respectively. 236 Thus, reducing the number of packets to be managed and switched will 237 reduce the overall energy consumption. The measurements deployed in 238 [Chabarek]on commercial routers corroborate this. A study using 239 different packet sizes was presented, and the tests with big packets 240 showed that energy consumption gets reduced, since a non-negligible 241 amount of energy is associated to header processing tasks, and not 242 only to the sending of the packet itself. 244 Some tests measuring the benefits of Simplemux were published in 245 [Saldana]. 247 2. Description of the scenario 249 Simplemux works between a pair of machines. It creates a tunnel 250 between an "ingress" and an "egress". They MAY be the endpoints of 251 the communication, but they MAY also be middleboxes able to multiplex 252 packets belonging to different flows. Different mechanisms MAY be 253 used in order to classify flows according to some criteria (sharing a 254 common path, kind of service, etc.) and to select the flows to be 255 multiplexed and sent to the egress (see Figure 2). 257 +-------+ 258 | | +---------+ +---------+ 259 | | ---> |Simplemux| _ _ |Simplemux| --> 260 |classif| ---> | ingress | ===> ( ` )_ ===> | egress | --> 261 | | +---------+ ( Network `) +---------+ 262 | | --------------------> (_ (_ . _) _) -----------------> 263 +-------+ 264 <--------Simplemux--------> 266 Figure 2 268 3. Protocol description 270 A Simplemux packet consists of: 272 - An external header that is used as the tunneling header for the 273 whole packet. 275 - A series of pairs "Simplemux header" + "packet" of the multiplexed 276 protocol. 278 This is the scheme of a Simplemux packet: 280 |tun hdr||Simplemux hdr|packet||Simplemux hdr|packet||...| 281 The Simplemux header has two different forms: one for the "First 282 Simplemux header," and another one for the rest of the Simplemux 283 headers (called "Non-first Simplemux headers"): 285 o First Simplemux header (after the tunneling header, and before the 286 first multiplexed packet): 288 In order to allow the multiplexing of packets of any length, the 289 number of bytes expressing the length is variable, and a field called 290 "Length Extension" (LXT, one bit) is used to flag if the current byte 291 is the last one including length information. This is the structure 292 of a First Simplemux header: 294 |SPB(1 bit)|LXT(1 bit)|length (6 bits)||LXT(1 bit)|length (7 295 bits)||...||Protocol (8 bits)| 297 - Single Protocol Bit (SPB, one bit) only appears in the first 298 Simplemux header. It is set to 1 if all the multiplexed packets 299 belong to the same protocol (in this case, the "Protocol" field will 300 only appear in the first Simplemux header). It is set to 0 when each 301 packet MAY belong to a different protocol. 303 - Length Extension (LXT, one bit) is 0 if the current byte is the 304 last byte where the length of the first packet is included, and 1 in 305 other case. 307 - Length (LEN, 6, 13, 20, etc. bits): This is the length of the 308 multiplexed packet (in bytes), not including the length field. If 309 the length of the multiplexed packet is less than 64 bytes (less than 310 or equal to 63 bytes), the first LXT is set to 0 and the 6 bits of 311 the length field are the length of the multiplexed packet. If the 312 length of the multiplexed packet is equal or greater than 64 bytes, 313 additional bytes are added. The first bit of each of the added bytes 314 is the LXT. If LXT is set to 1, it means that there is an additional 315 byte for expressing the length. This allows to multiplex packets of 316 any length (see the next figures). 318 - Protocol (8 bits) is the Protocol field of the multiplexed packet, 319 according to IANA "Assigned Internet Protocol Numbers." 321 As an example, a First Simplemux header before a packet smaller than 322 64 (2^6) bytes would be 2 bytes long: 324 0 1 325 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |S|L| | | 328 |P|X| Length | Protocol | 329 |B|T| (6 bits) | (8 bits) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 ^ 332 0 334 Figure 3 336 A First Simplemux header before a packet with a length greater or 337 equal to 64 bytes, and smaller than 8192 bytes (2^13) will be 3 bytes 338 long: 340 0 1 2 341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 |S|L| |L| | | 344 |P|X| Length 1 |X| Length 2 | Protocol | 345 |B|T| (6 bits) |T| (7 bits) | (8 bits) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 ^ ^ 348 1 0 350 Figure 4 352 In this case, the length of the packet will be the number expressed 353 by the concatenation of the bits of Length 1 - Length 2 (total 13 354 bits). Length 1 includes the 6 most significant bits and Length 2 355 the 7 less significant bits. 357 A First Simplemux header before a packet with a length greater of 358 equal to 8192 bytes, and smaller than 1048576 bytes (2^20) would be 4 359 bytes long: 361 0 1 2 3 362 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |S|L| |L| |L| | | 365 |P|X| Length 1 |X| Length 2 |X| Length 3 | Protocol | 366 |B|T| (6 bits) |T| (7 bits) |T| (7 bits) | (8 bits) | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 ^ ^ ^ 369 1 1 0 371 Figure 5 373 In this case, the length of the packet will be the number expressed 374 by the concatenation of the bits of Length 1 - Length 2 - Length 3 375 (total 20 bits). Length 1 includes the 6 most significant bits and 376 Length 3 the less 7 significant bits. 378 More bytes can be added to the length if required, using the same 379 scheme: 1 LXT byte plus 7 bits for expressing the length. 381 o Subsequent (Non-first) Simplemux headers (before the other 382 packets): 384 The Non-first Simplemux headers also employ a format allowing the 385 multiplexing of packets of any length, so the number of bytes 386 expressing the length is variable, and the field Length Extension 387 (LXT, one bit) is used to flag if the current byte is the last one 388 including length information. This is the structure of a Non-first 389 Simplemux header: 391 |LXT(1 bit)|length (7 bits)||LXT(1 bit)|length (7 392 bits)||...||Protocol (8 bits, optional)| 394 - Length Extension (LXT, one bit) is 0 if the current byte is the 395 last byte where the length of the packet is included, and 1 in other 396 case. 398 - Length (LEN, 7, 14, 21, etc. bits): This is the length of the 399 multiplexed packet (in bytes), not including the length field. If 400 the length of the multiplexed packet is less than 128 bytes (less 401 than or equal to 127 bytes), LXT is set to 0 and the 7 bits of the 402 length field represent the length of the multiplexed packet. If the 403 length of the multiplexed packet is greater than 127 bytes, 404 additional bytes are added. The first bit of each of the added bytes 405 is the LXT. If LXT is set to 1, it means that there is an additional 406 byte for expressing the length. This allows to multiplex packets of 407 any length (see the next figures). 409 - Protocol (8 bits) is the Protocol field of the multiplexed packet, 410 according to IANA "Assigned Internet Protocol Numbers". It only 411 appears in Non-first headers if the Single Protocol Bit (SPB) of the 412 First Simplemux header is set to 1. 414 As an example, a Non-first Simplemux header before a packet smaller 415 than 128 bytes, when the protocol bit has been set to 0 in the first 416 header, would be 1 byte long: 418 0 419 0 1 2 3 4 5 6 7 420 +-+-+-+-+-+-+-+-+ 421 |L| | 422 |X| Length | 423 |T| (7 bits) | 424 +-+-+-+-+-+-+-+-+ 425 ^ 426 0 428 SPB = 0 in the first header 430 Figure 6 432 A Non-first Simplemux header before a packet witha a length greater 433 or equal to 128 bytes, and smaller than 16384 (2^14), when the 434 protocol bit has been set to 0 in the first header, will be 2 bytes 435 long: 437 0 1 438 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |L| |L| | 441 |X| Length 1 |X| Length 2 | 442 |T| (7 bits) |T| (7 bits) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 ^ ^ 445 1 0 447 SPB = 0 in the first header 449 Figure 7 451 A Non-first Simplemux header before a packet with a length greater or 452 equal to 16384 bytes, and smaller than 2097152 bytes (2^21), when the 453 protocol bit has been set to 0 in the first header, will be 3 bytes 454 long: 456 0 1 2 457 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 |L| |L| |L| | 460 |X| Length 1 |X| Length 2 |X| Length 3 | 461 |T| (7 bits) |T| (7 bits) |T| (7 bits) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 ^ ^ ^ 464 1 1 0 466 SPB = 0 in the first header 468 Figure 8 470 In this case, the length of the packet will be the number expressed 471 by the concatenation of the bits of Length 1 - Length 2 - Length 3 472 (total 21 bits). Length 1 includes the 7 most significant bits and 473 Length 3 the 7 less significant bits. 475 More bytes can be added to the length if required, using the same 476 scheme: 1 LXT byte plus 7 bits for expressing the length. 478 A Non-first Simplemux header before a packet smaller than 128 bytes, 479 when the protocol bit has been set to 1 in the first header, will be 480 2 bytes long: 482 0 1 483 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |L| | | 486 |X| Length | Protocol | 487 |T| (7 bits) | (8 bits) | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 ^ 490 0 492 SPB = 1 in the first header 494 Figure 9 496 A Non-first Simplemux header before a packet with a length greater or 497 equal to 128 bytes, and smaller than 16384 (2^14), when the protocol 498 bit has been set to 1 in the first header, will be 3 bytes long: 500 0 1 2 501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 |L| |L| | | 504 |X| Length 1 |X| Length 2 | Protocol | 505 |T| (7 bits) |T| (7 bits) | (8 bits) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 ^ ^ 508 1 0 510 SPB = 1 in the first header 512 Figure 10 514 A Non-first Simplemux header before a packet with a length greater of 515 equal to 16384 bytes, and smaller than 2097152 bytes (2^21), when the 516 protocol bit has been set to 1 in the first header, will be 4 bytes 517 long: 519 0 1 2 3 520 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 |L| |L| |L| | | 523 |X| Length 1 |X| Length 2 |X| Length 3 | Protocol | 524 |T| (7 bits) |T| (7 bits) |T| (7 bits) | (8 bits) | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 ^ ^ ^ 527 1 1 0 529 SPB = 1 in the first header 531 Figure 11 533 In this case, the length of the packet will be the number expressed 534 by the concatenation of the bits of Length 1 - Length 2 - Length 3 535 (total 21 bits). Length 1 includes the 7 most significant bits and 536 Length 3 the 7 less significant bits. 538 More bytes can be added to the length if required, using the same 539 scheme: 1 LXT byte plus 7 bits for expressing the length. 541 These would be some examples of the whole bundles: 543 Case 1: All the packets belong to the same protocol: The first 544 Simplemux header would be 2 or 3 bytes (for usual packet sizes), and 545 the other Simplemux headers would be 1 or 2 bytes. For small packets 546 (< 128 bytes), the Simplemux header would only require one byte. 548 |tun||1|0|len|Protocol|pkt||0|len|pkt||1|len|0|len|pkt||...| 549 | | | | 550 v v v v 551 (6 bits) (7 bits) (14 bits) 553 |tun||1|1|len|0|len|Protocol|pkt||0|len|pkt||1|len|0|len|pkt||...| 554 | | | | | 555 v v v v v 556 (13 bits) (7 bits) (14 bits) 558 Figure 12 560 Case 2: Each packet may belong to a different protocol: All the 561 Simplemux headers would be 2 or 3 bytes (for usual packet sizes). 563 |tun||0|0|len|Prot|pkt||0|len|Prot|pkt||1|len|0|len|Prot|pkt||...| 564 | | | | 565 v v v v 566 (6 bits) (7 bits) (14 bits) 568 |tun||0|1|len|0|len|Prot|pkt||0|len|Prot|pkt||1|len|0|len|Prot|pkt||...| 569 | | | | | 570 v v v v v 571 (13 bits) (7 bits) (14 bits) 573 Figure 13 575 4. Acknowledgements 577 This work has been partially funded by the EU H2020 Wi-5 project 578 (Grant Agreement no: 644262), the Spanish Ministry of Economy and 579 Competitiveness project TIN2015-64770-R, in cooperation with the 580 European Regional Development Fund (TIN2016-76770-R) and Gobierno de 581 Aragon and FEDER "Construyendo Europa desde Aragon" (Research Group 582 T31_17R). 584 5. IANA Considerations 586 A protocol number for Simplemux should be requested to IANA. 588 As a provisional solution for IP networks, the ingress and the egress 589 optimizers may agree on a UDP port, and use IP/UDP as the 590 multiplexing protocol. 592 6. Security Considerations 594 Simplemux protocol has been developed in such a way that packet 595 aggregation and security can be simultaneously applied to the same 596 traffic flows, i.e. a single security header could protect a number 597 of packets belonging to different flows. 599 As a consequence, the overall efficiency could be improved, as the 600 number of security headers could be reduced from N to 1 (being N the 601 number of multiplexed packets). 603 7. References 605 7.1. Normative References 607 [RFC1570] Simpson, W., Ed., "PPP LCP Extensions", RFC 1570, 608 DOI 10.17487/RFC1570, January 1994, 609 . 611 [RFC1692] Cameron, P., Crocker, D., Cohen, D., and J. Postel, 612 "Transport Multiplexing Protocol (TMux)", RFC 1692, 613 DOI 10.17487/RFC1692, August 1994, 614 . 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, 618 DOI 10.17487/RFC2119, March 1997, 619 . 621 [RFC3153] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", 622 RFC 3153, DOI 10.17487/RFC3153, August 2001, 623 . 625 [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling 626 Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, 627 DOI 10.17487/RFC4170, November 2005, 628 . 630 7.2. Informative References 632 [Bolla] Bolla, R., Bruschi, R., Davoli, F., and F. Cucchietti, 633 "Energy Efficiency in the Future Internet: A Survey of 634 Existing Approaches and Trends in Energy-Aware Fixed 635 Network Infrastructures", IEEE Communications Surveys and 636 Tutorials vol.13, no.2, pp.223,244, 2011. 638 [Chabarek] 639 Chabarek, J., Sommers, J., Barford, P., Estan, C., Tsiang, 640 D., and S. Wright, "Power Awareness in Network Design and 641 Routing", INFOCOM 2008. The 27th Conference on Computer 642 Communications. IEEE pp.457,465, 2008. 644 [Saldana] Saldana, J., Forcen, I., Fernandez-Navajas, J., and J. 645 Ruiz-Mas, "Improving Network Efficiency with Simplemux", 646 IEEE CIT 2015, International Conference on Computer and 647 Information Technology pp. 446-453, 26-28 October 2015, 648 Liverpool, UK., 2015. 650 Authors' Addresses 652 Jose Saldana 653 University of Zaragoza 654 Dpt. IEC Ada Byron Building 655 Zaragoza 50018 656 Spain 658 Phone: +34 976 762 698 659 Email: jsaldana@unizar.es 661 Julian Fernandez Navajas 662 University of Zaragoza 663 Dpt. IEC Ada Byron Building 664 Zaragoza 50018 665 Spain 667 Phone: +34 976 761 963 668 Email: navajas@unizar.es 670 Jose Ruiz Mas 671 University of Zaragoza 672 Dpt. IEC Ada Byron Building 673 Zaragoza 50018 674 Spain 676 Phone: +34 976 762 158 677 Email: jruiz@unizar.es