idnits 2.17.1 draft-saldana-tsvwg-simplemux-08.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 (August 31, 2017) is 2428 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 618, 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: March 4, 2018 University of Zaragoza 6 August 31, 2017 8 Simplemux. A generic multiplexing protocol 9 draft-saldana-tsvwg-simplemux-08 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 a number of small packets into a bigger 17 one is desirable in order to improve the efficiency. For example, a 18 number of small packets can be sent together between a pair of 19 machines if they share a common network path. Thus, the traffic 20 profile can be shifted from small to larger packets, reducing the 21 network overhead and the number of packets per second to be managed 22 by intermediate routers. 24 This document describes Simplemux, a protocol able to encapsulate a 25 number of packets belonging to different protocols into a single 26 packet. Small headers (separators) are added at the beginning of 27 each multiplexed packet, including some flags, the packet length and 28 a "Protocol" field. This allows the inclusion of a number of packets 29 belonging to different protocols (the "multiplexed packets") on a 30 packet of another protocol (the "tunneling protocol"). 32 In order to reduce the overhead, the size of the multiplexing headers 33 is kept very low (it may be a single byte when multiplexing small 34 packets). 36 Status of This Memo 38 This Internet-Draft is submitted to IETF in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 4, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 1.2. Existing multiplexing protocols . . . . . . . . . . . . . 3 70 1.3. Benefits of multiplexing . . . . . . . . . . . . . . . . 5 71 2. Description of the scenario . . . . . . . . . . . . . . . . . 6 72 3. Protocol description . . . . . . . . . . . . . . . . . . . . 6 73 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 7.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 The high amount of small packets present in nowaday's networks 84 results in a low efficiency, when the size of the headers and the 85 payload are in the same order of magnitude. In some situations, 86 multiplexing a number of small packets into a bigger one is desirable 87 in order to improve the efficiency. For example, a number of small 88 packets can be sent together between a pair of machines if they share 89 a common network path. Thus, the traffic profile can be shifted from 90 small to larger packets, thus reducing the network overhead and the 91 number of packets per second to be managed by intermediate routers. 93 This document describes Simplemux, a protocol able to encapsulate a 94 number of packets belonging to different protocols into a single 95 packet. This can be useful e.g. for grouping small packets and thus 96 reducing the number of packets per second in a network. 98 Simplemux is a generic multiplexing protocol, i.e. it can be used to 99 aggregate a number of packets belonging to a protocol, on a single 100 packet belonging to other (or the same) protocol. Thus, in this 101 document we will talk about the "multiplexed" protocol, and the 102 "tunneling" protocol, being Simplemux the "multiplexing" protocol. 103 The "external header" will be the one of the "tunneling" protocol 104 (see the figure (Figure 1)) 106 +--------------------------------+ 107 | Multiplexed Packet | Multiplexed protocol 108 +--------------------------------+ 109 | Simplemux | Multiplexing protocol 110 +--------------------------------+ 111 | Tunneling header | Tunneling protocol 112 +--------------------------------+ 114 Figure 1 116 As an example, if a number of small IPv6 packets have to travel over 117 an IPv4 network, they can be multiplexed and put into a single IPv4 118 packet. In this case, IPv4 is the "tunneling" protocol and IPv6 is 119 the "multiplexed" protocol. The IPv4 header is called in this case 120 the "tunneling" or the "external" header. The simplified scheme of 121 this packet would be: 123 |IPv4 hdr||Simplemux hdr|IPv6 packet||Simplemux hdr|IPv6 packet||...| 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 1.2. Existing multiplexing protocols 133 Different multiplexing protocols have been approved by the IETF in 134 the past: 136 o TMux [RFC1692] 138 TMux is able to combine multiple short transport segments, 139 independent of application type, and send them between a server and 140 host pair. As stated in the reference, "The TMux protocol is 141 intended to optimize the transmission of large numbers of small data 142 packets. In particular, communication load is not measured only in 143 bits per seconds but also in packets per seconds, and in many 144 situation the latter is the true performance limit, not the former. 145 The proposed multiplexing is aimed at alleviating this situation." 147 A TMux message appears as: 149 |IP hdr||TMux hdr|Transport segment||TMux hdr|Transport segment||...| 151 Therefore, the Transport Segment is not an entire IP packet, since it 152 does not include the IP header. 154 TMux works "between a server and host pair," so it multiplexes a 155 number of segments between the same pair of machines. However, there 156 are scenarios where a number of low-efficiency flows share a common 157 path, but they do not travel between the same pair of machines. 159 o PPPMux [RFC3153] 161 PPPMux "sends multiple PPP encapsulated packets in a single PPP 162 frame. As a result, the PPP overhead per packet is reduced." Thus, 163 it is able to multiplex complete IP packets, using separators. 165 However, the use of PPPMux requires the use of PPP and L2TP in order 166 to multiplex a number of packets together, as done in TCRTP 167 [RFC4170]. Thus, it introduces more overhead and complexity. 169 An IP packet including a number of them using PPPMux appears as: 171 |IP hdr|L2TP hdr|PPP hdr||PPPMux hdr|packet||PPPMux hdr|packet||...| 173 The scheme proposed by PPPMux is similar to the Compound-Frames of 174 PPP LCP Extensions [RFC1570]. The key differences are that PPPMux is 175 more efficient and that it allows concatenation of variable sized 176 frames. 178 *** 180 The definition of a protocol able to multiplex complete packets, 181 avoiding the need of other protocols as PPP is seen as convenient. 182 The multiplexed packets can be of any kind, since a "Protocol Number" 183 field can be added to each of them. Not all the packets multiplexed 184 together must belong to the same protocol. The general scheme of 185 Simplemux is: 187 |tunnel hdr||Simplemux hdr|packet||Simplemux hdr|packet||...| 188 The Simplemux header includes the "Protocol Number" field, so it 189 permits the multiplexing of different kinds of packets in the same 190 bundle. 192 We will also refer to the Simplemux header with the terms 193 "separator," "Simplemux separator" or "mux separator". In the 194 figures we will also use the abbreviation "Smux". 196 When applied to IP packets, the scheme of a multiplexed packet 197 becomes: 199 |tunnel hdr||Simplemux hdr|IP packet||Simplemux hdr|IP packet||...| 201 1.3. Benefits of multiplexing 203 The benefits of multiplexing are: 205 - Tunneling a number of packets together. If a number of packets 206 have to be tunneled through a network segment, they can be 207 multiplexed and then sent together using a single external header. 208 This will avoid the need for adding a tunneling header to each of the 209 packets, thus reducing the overhead. 211 - Reduction of the amount of packets per second in the network. It 212 is desirable for two main reasons: first, network equipment has a 213 limitation in terms of the number of packets per second it can 214 manage, i.e. many devices are not able to send small packets back to 215 back due to processing delay. 217 - Bandwidth reduction. The presence of high rates of tiny packets 218 translates into an inefficient usage of network resources, so there 219 is a need for mechanisms able to reduce the overhead introduced by 220 low-efficiency flows. When combined with header compression, as done 221 in TCRTP [RFC4170] multiplexing may produce significant bandwidth 222 savings, which are interesting for network operators, since they may 223 alleviate the traffic load in their networks. 225 - Energy savings: a lower amount of packets per second will reduce 226 energy consumption in network equipment since, according to [Bolla], 227 internal packet processing engines and switching fabric require 60% 228 and 18% of the power consumption of high-end routers respectively. 229 Thus, reducing the number of packets to be managed and switched will 230 reduce the overall energy consumption. The measurements deployed in 231 [Chabarek]on commercial routers corroborate this. A study using 232 different packet sizes was presented, and the tests with big packets 233 showed that energy consumption gets reduced, since a non-negligible 234 amount of energy is associated to header processing tasks, and not 235 only to the sending of the packet itself. 237 2. Description of the scenario 239 Simplemux works between a pair of machines. It creates a tunnel 240 between an "ingress" and an "egress". They MAY be the endpoints of 241 the communication, but they MAY also be middleboxes able to multiplex 242 packets belonging to different flows. Different mechanisms MAY be 243 used in order to classify flows according to some criteria (sharing a 244 common path, kind of service, etc.) and to select the flows to be 245 multiplexed and sent to the egress (see Figure 2). 247 +-------+ 248 | | +---------+ +---------+ 249 | | ---> |Simplemux| _ _ |Simplemux| --> 250 |classif| ---> | ingress | ===> ( ` )_ ===> | egress | --> 251 | | +---------+ ( Network `) +---------+ 252 | | --------------------> (_ (_ . _) _) -----------------> 253 +-------+ 254 <--------Simplemux--------> 256 Figure 2 258 3. Protocol description 260 A Simplemux packet consists of: 262 - An external header that is used as the tunneling header for the 263 whole packet. 265 - A series of pairs "Simplemux header" + "packet" of the multiplexed 266 protocol. 268 This is the scheme of a Simplemux packet: 270 |tun hdr||Simplemux hdr|packet||Simplemux hdr|packet||...| 272 The Simplemux header has two different forms: one for the "First 273 Simplemux header," and another one for the rest of the Simplemux 274 headers (called "Non-first Simplemux headers"): 276 o First Simplemux header (after the tunneling header, and before the 277 first multiplexed packet): 279 In order to allow the multiplexing of packets of any length, the 280 number of bytes expressing the length is variable, and a field called 281 "Length Extension" (LXT, one bit) is used to flag if the current byte 282 is the last one including length information. This is the structure 283 of a First Simplemux header: 285 |SPB(1 bit)|LXT(1 bit)|length (6 bits)||LXT(1 bit)|length (7 286 bits)||...||Protocol (8 bits)| 288 - Single Protocol Bit (SPB, one bit) only appears in the first 289 Simplemux header. It is set to 1 if all the multiplexed packets 290 belong to the same protocol (in this case, the "Protocol" field will 291 only appear in the first Simplemux header). It is set to 0 when each 292 packet MAY belong to a different protocol. 294 - Length Extension (LXT, one bit) is 0 if the current byte is the 295 last byte where the length of the first packet is included, and 1 in 296 other case. 298 - Length (LEN, 6, 13, 20, etc. bits): This is the length of the 299 multiplexed packet (in bytes), not including the length field. If 300 the length of the multiplexed packet is less than 64 bytes (less than 301 or equal to 63 bytes), the first LXT is set to 0 and the 6 bits of 302 the length field are the length of the multiplexed packet. If the 303 length of the multiplexed packet is equal or greater than 64 bytes, 304 additional bytes are added. The first bit of each of the added bytes 305 is the LXT. If LXT is set to 1, it means that there is an additional 306 byte for expressing the length. This allows to multiplex packets of 307 any length (see the next figures). 309 - Protocol (8 bits) is the Protocol field of the multiplexed packet, 310 according to IANA "Assigned Internet Protocol Numbers." 312 As an example, a First Simplemux header before a packet smaller than 313 64 (2^6) bytes would be 2 bytes long: 315 0 1 316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |S|L| | | 319 |P|X| Length | Protocol | 320 |B|T| (6 bits) | (8 bits) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 ^ 323 0 325 Figure 3 327 A First Simplemux header before a packet with a length greater or 328 equal to 64 bytes, and smaller than 8192 bytes (2^13) will be 3 bytes 329 long: 331 0 1 2 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |S|L| |L| | | 335 |P|X| Length 1 |X| Length 2 | Protocol | 336 |B|T| (6 bits) |T| (7 bits) | (8 bits) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 ^ ^ 339 1 0 341 Figure 4 343 In this case, the length of the packet will be the number expressed 344 by the concatenation of the bits of Length 1 - Length 2 (total 13 345 bits). Length 1 includes the 6 most significant bits and Length 2 346 the 7 less significant bits. 348 A First Simplemux header before a packet with a length greater of 349 equal to 8192 bytes, and smaller than 1048576 bytes (2^20) would be 4 350 bytes long: 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |S|L| |L| |L| | | 356 |P|X| Length 1 |X| Length 2 |X| Length 3 | Protocol | 357 |B|T| (6 bits) |T| (7 bits) |T| (7 bits) | (8 bits) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 ^ ^ ^ 360 1 1 0 362 Figure 5 364 In this case, the length of the packet will be the number expressed 365 by the concatenation of the bits of Length 1 - Length 2 - Length 3 366 (total 20 bits). Length 1 includes the 6 most significant bits and 367 Length 3 the less 7 significant bits. 369 More bytes can be added to the length if required, using the same 370 scheme: 1 LXT byte plus 7 bits for expressing the length. 372 o Subsequent (Non-first) Simplemux headers (before the other 373 packets): 375 The Non-first Simplemux headers also employ a format allowing the 376 multiplexing of packets of any length, so the number of bytes 377 expressing the length is variable, and the field Length Extension 378 (LXT, one bit) is used to flag if the current byte is the last one 379 including length information. This is the structure of a Non-first 380 Simplemux header: 382 |LXT(1 bit)|length (7 bits)||LXT(1 bit)|length (7 383 bits)||...||Protocol (8 bits, optional)| 385 - Length Extension (LXT, one bit) is 0 if the current byte is the 386 last byte where the length of the packet is included, and 1 in other 387 case. 389 - Length (LEN, 7, 14, 21, etc. bits): This is the length of the 390 multiplexed packet (in bytes), not including the length field. If 391 the length of the multiplexed packet is less than 128 bytes (less 392 than or equal to 127 bytes), LXT is set to 0 and the 7 bits of the 393 length field represent the length of the multiplexed packet. If the 394 length of the multiplexed packet is greater than 127 bytes, 395 additional bytes are added. The first bit of each of the added bytes 396 is the LXT. If LXT is set to 1, it means that there is an additional 397 byte for expressing the length. This allows to multiplex packets of 398 any length (see the next figures). 400 - Protocol (8 bits) is the Protocol field of the multiplexed packet, 401 according to IANA "Assigned Internet Protocol Numbers". It only 402 appears in Non-first headers if the Single Protocol Bit (SPB) of the 403 First Simplemux header is set to 1. 405 As an example, a Non-first Simplemux header before a packet smaller 406 than 128 bytes, when the protocol bit has been set to 0 in the first 407 header, would be 1 byte long: 409 0 410 0 1 2 3 4 5 6 7 411 +-+-+-+-+-+-+-+-+ 412 |L| | 413 |X| Length | 414 |T| (7 bits) | 415 +-+-+-+-+-+-+-+-+ 416 ^ 417 0 419 SPB = 0 in the first header 421 Figure 6 423 A Non-first Simplemux header before a packet witha a length greater 424 or equal to 128 bytes, and smaller than 16384 (2^14), when the 425 protocol bit has been set to 0 in the first header, will be 2 bytes 426 long: 428 0 1 429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |L| |L| | 432 |X| Length 1 |X| Length 2 | 433 |T| (7 bits) |T| (7 bits) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 ^ ^ 436 1 0 438 SPB = 0 in the first header 440 Figure 7 442 A Non-first Simplemux header before a packet with a length greater or 443 equal to 16384 bytes, and smaller than 2097152 bytes (2^21), when the 444 protocol bit has been set to 0 in the first header, will be 3 bytes 445 long: 447 0 1 2 448 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |L| |L| |L| | 451 |X| Length 1 |X| Length 2 |X| Length 3 | 452 |T| (7 bits) |T| (7 bits) |T| (7 bits) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 ^ ^ ^ 455 1 1 0 457 SPB = 0 in the first header 459 Figure 8 461 In this case, the length of the packet will be the number expressed 462 by the concatenation of the bits of Length 1 - Length 2 - Length 3 463 (total 21 bits). Length 1 includes the 7 most significant bits and 464 Length 3 the 7 less significant bits. 466 More bytes can be added to the length if required, using the same 467 scheme: 1 LXT byte plus 7 bits for expressing the length. 469 A Non-first Simplemux header before a packet smaller than 128 bytes, 470 when the protocol bit has been set to 1 in the first header, will be 471 2 bytes long: 473 0 1 474 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |L| | | 477 |X| Length | Protocol | 478 |T| (7 bits) | (8 bits) | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 ^ 481 0 483 SPB = 1 in the first header 485 Figure 9 487 A Non-first Simplemux header before a packet with a length greater or 488 equal to 128 bytes, and smaller than 16384 (2^14), when the protocol 489 bit has been set to 1 in the first header, will be 3 bytes long: 491 0 1 2 492 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 |L| |L| | | 495 |X| Length 1 |X| Length 2 | Protocol | 496 |T| (7 bits) |T| (7 bits) | (8 bits) | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 ^ ^ 499 1 0 501 SPB = 1 in the first header 503 Figure 10 505 A Non-first Simplemux header before a packet with a length greater of 506 equal to 16384 bytes, and smaller than 2097152 bytes (2^21), when the 507 protocol bit has been set to 1 in the first header, will be 4 bytes 508 long: 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |L| |L| |L| | | 514 |X| Length 1 |X| Length 2 |X| Length 3 | Protocol | 515 |T| (7 bits) |T| (7 bits) |T| (7 bits) | (8 bits) | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 ^ ^ ^ 518 1 1 0 520 SPB = 1 in the first header 522 Figure 11 524 In this case, the length of the packet will be the number expressed 525 by the concatenation of the bits of Length 1 - Length 2 - Length 3 526 (total 21 bits). Length 1 includes the 7 most significant bits and 527 Length 3 the 7 less significant bits. 529 More bytes can be added to the length if required, using the same 530 scheme: 1 LXT byte plus 7 bits for expressing the length. 532 These would be some examples of the whole bundles: 534 Case 1: All the packets belong to the same protocol: The first 535 Simplemux header would be 2 or 3 bytes (for usual packet sizes), and 536 the other Simplemux headers would be 1 or 2 bytes. For small packets 537 (< 128 bytes), the Simplemux header would only require one byte. 539 |tun||1|0|len|Protocol|pkt||0|len|pkt||1|len|0|len|pkt||...| 540 | | | | 541 v v v v 542 (6 bits) (7 bits) (14 bits) 544 |tun||1|1|len|0|len|Protocol|pkt||0|len|pkt||1|len|0|len|pkt||...| 545 | | | | | 546 v v v v v 547 (13 bits) (7 bits) (14 bits) 549 Figure 12 551 Case 2: Each packet may belong to a different protocol: All the 552 Simplemux headers would be 2 or 3 bytes (for usual packet sizes). 554 |tun||0|0|len|Prot|pkt||0|len|Prot|pkt||1|len|0|len|Prot|pkt||...| 555 | | | | 556 v v v v 557 (6 bits) (7 bits) (14 bits) 559 |tun||0|1|len|0|len|Prot|pkt||0|len|Prot|pkt||1|len|0|len|Prot|pkt||...| 560 | | | | | 561 v v v v v 562 (13 bits) (7 bits) (14 bits) 564 Figure 13 566 4. Acknowledgements 568 This work has been partially funded by the EU H2020 Wi-5 project 569 (Grant Agreement no: 644262) and the Spanish Ministry of Economy and 570 Competitiveness project TIN2015-64770-R, in cooperation with the 571 European Regional Development Fund. 573 5. IANA Considerations 575 A protocol number for Simplemux should be requested to IANA. 577 As a provisional solution for IP networks, the ingress and the egress 578 optimizers may agree on a UDP port, and use IP/UDP as the 579 multiplexing protocol. 581 6. Security Considerations 583 7. References 585 7.1. Normative References 587 [RFC1570] Simpson, W., Ed., "PPP LCP Extensions", RFC 1570, 588 DOI 10.17487/RFC1570, January 1994, . 591 [RFC1692] Cameron, P., Crocker, D., Cohen, D., and J. Postel, 592 "Transport Multiplexing Protocol (TMux)", RFC 1692, 593 DOI 10.17487/RFC1692, August 1994, . 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, . 601 [RFC3153] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", 602 RFC 3153, DOI 10.17487/RFC3153, August 2001, 603 . 605 [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling 606 Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, 607 DOI 10.17487/RFC4170, November 2005, . 610 7.2. Informative References 612 [Bolla] Bolla, R., Bruschi, R., Davoli, F., and F. Cucchietti, 613 "Energy Efficiency in the Future Internet: A Survey of 614 Existing Approaches and Trends in Energy-Aware Fixed 615 Network Infrastructures", IEEE Communications Surveys and 616 Tutorials vol.13, no.2, pp.223,244, 2011. 618 [Chabarek] 619 Chabarek, J., Sommers, J., Barford, P., Estan, C., Tsiang, 620 D., and S. Wright, "Power Awareness in Network Design and 621 Routing", INFOCOM 2008. The 27th Conference on Computer 622 Communications. IEEE pp.457,465, 2008. 624 Authors' Addresses 626 Jose Saldana 627 University of Zaragoza 628 Dpt. IEC Ada Byron Building 629 Zaragoza 50018 630 Spain 632 Phone: +34 976 762 698 633 Email: jsaldana@unizar.es 635 Julian Fernandez Navajas 636 University of Zaragoza 637 Dpt. IEC Ada Byron Building 638 Zaragoza 50018 639 Spain 641 Phone: +34 976 761 963 642 Email: navajas@unizar.es 643 Jose Ruiz Mas 644 University of Zaragoza 645 Dpt. IEC Ada Byron Building 646 Zaragoza 50018 647 Spain 649 Phone: +34 976 762 158 650 Email: jruiz@unizar.es