idnits 2.17.1 draft-saldana-tsvwg-simplemux-07.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 (July 31, 2017) is 2459 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 615, 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 University of Zaragoza 4 Intended status: Standards Track July 31, 2017 5 Expires: February 1, 2018 7 Simplemux. A generic multiplexing protocol 8 draft-saldana-tsvwg-simplemux-07 10 Abstract 12 The high amount of small packets present in nowaday's networks 13 results in a low efficiency, as the size of the headers and the 14 payload of these packets can be in the same order of magnitude. In 15 some situations, multiplexing a number of small packets into a bigger 16 one is desirable in order to improve the efficiency. For example, a 17 number of small packets can be sent together between a pair of 18 machines if they share a common network path. Thus, the traffic 19 profile can be shifted from small to larger packets, reducing the 20 network overhead and the number of packets per second to be managed 21 by intermediate routers. 23 This document describes Simplemux, a protocol able to encapsulate a 24 number of packets belonging to different protocols into a single 25 packet. Small headers (separators) are added at the beginning of 26 each multiplexed packet, including some flags, the packet length and 27 a "Protocol" field. This allows the inclusion of a number of packets 28 belonging to different protocols (the "multiplexed packets") on a 29 packet of another protocol (the "tunneling protocol"). 31 In order to reduce the overhead, the size of the multiplexing headers 32 is kept very low (it may be a single byte when multiplexing small 33 packets). 35 Status of This Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 1, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 1.2. Existing multiplexing protocols . . . . . . . . . . . . . 3 68 1.3. Benefits of multiplexing . . . . . . . . . . . . . . . . 5 69 2. Description of the scenario . . . . . . . . . . . . . . . . . 6 70 3. Protocol description . . . . . . . . . . . . . . . . . . . . 6 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 7.2. Informative References . . . . . . . . . . . . . . . . . 14 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 The high amount of small packets present in nowaday's networks 82 results in a low efficiency, when the size of the headers and the 83 payload are in the same order of magnitude. In some situations, 84 multiplexing a number of small packets into a bigger one is desirable 85 in order to improve the efficiency. For example, a number of small 86 packets can be sent together between a pair of machines if they share 87 a common network path. Thus, the traffic profile can be shifted from 88 small to larger packets, thus reducing the network overhead and the 89 number of packets per second to be managed by intermediate routers. 91 This document describes Simplemux, a protocol able to encapsulate a 92 number of packets belonging to different protocols into a single 93 packet. This can be useful e.g. for grouping small packets and thus 94 reducing the number of packets per second in a network. 96 Simplemux is a generic multiplexing protocol, i.e. it can be used to 97 aggregate a number of packets belonging to a protocol, on a single 98 packet belonging to other (or the same) protocol. Thus, in this 99 document we will talk about the "multiplexed" protocol, and the 100 "tunneling" protocol, being Simplemux the "multiplexing" protocol. 101 The "external header" will be the one of the "tunneling" protocol 102 (see the figure (Figure 1)) 104 +--------------------------------+ 105 | Multiplexed Packet | Multiplexed protocol 106 +--------------------------------+ 107 | Simplemux | Multiplexing protocol 108 +--------------------------------+ 109 | Tunneling header | Tunneling protocol 110 +--------------------------------+ 112 Figure 1 114 As an example, if a number of small IPv6 packets have to travel over 115 an IPv4 network, they can be multiplexed and put into a single IPv4 116 packet. In this case, IPv4 is the "tunneling" protocol and IPv6 is 117 the "multiplexed" protocol. The IPv4 header is called in this case 118 the "tunneling" or the "external" header. The simplified scheme of 119 this packet would be: 121 |IPv4 hdr||Simplemux hdr|IPv6 packet||Simplemux hdr|IPv6 packet||...| 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 1.2. Existing multiplexing protocols 131 Different multiplexing protocols have been approved by the IETF in 132 the past: 134 o TMux [RFC1692] 136 TMux is able to combine multiple short transport segments, 137 independent of application type, and send them between a server and 138 host pair. As stated in the reference, "The TMux protocol is 139 intended to optimize the transmission of large numbers of small data 140 packets. In particular, communication load is not measured only in 141 bits per seconds but also in packets per seconds, and in many 142 situation the latter is the true performance limit, not the former. 143 The proposed multiplexing is aimed at alleviating this situation." 145 A TMux message appears as: 147 |IP hdr||TMux hdr|Transport segment||TMux hdr|Transport segment||...| 149 Therefore, the Transport Segment is not an entire IP packet, since it 150 does not include the IP header. 152 TMux works "between a server and host pair," so it multiplexes a 153 number of segments between the same pair of machines. However, there 154 are scenarios where a number of low-efficiency flows share a common 155 path, but they do not travel between the same pair of machines. 157 o PPPMux [RFC3153] 159 PPPMux "sends multiple PPP encapsulated packets in a single PPP 160 frame. As a result, the PPP overhead per packet is reduced." Thus, 161 it is able to multiplex complete IP packets, using separators. 163 However, the use of PPPMux requires the use of PPP and L2TP in order 164 to multiplex a number of packets together, as done in TCRTP 165 [RFC4170]. Thus, it introduces more overhead and complexity. 167 An IP packet including a number of them using PPPMux appears as: 169 |IP hdr|L2TP hdr|PPP hdr||PPPMux hdr|packet||PPPMux hdr|packet||...| 171 The scheme proposed by PPPMux is similar to the Compound-Frames of 172 PPP LCP Extensions [RFC1570]. The key differences are that PPPMux is 173 more efficient and that it allows concatenation of variable sized 174 frames. 176 *** 178 The definition of a protocol able to multiplex complete packets, 179 avoiding the need of other protocols as PPP is seen as convenient. 180 The multiplexed packets can be of any kind, since a "Protocol Number" 181 field can be added to each of them. Not all the packets multiplexed 182 together must belong to the same protocol. The general scheme of 183 Simplemux is: 185 |tunnel hdr||Simplemux hdr|packet||Simplemux hdr|packet||...| 187 The Simplemux header includes the "Protocol Number" field, so it 188 permits the multiplexing of different kinds of packets in the same 189 bundle. 191 We will also refer to the Simplemux header with the terms 192 "separator," "Simplemux separator" or "mux separator". In the 193 figures we will also use the abbreviation "Smux". 195 When applied to IP packets, the scheme of a multiplexed packet 196 becomes: 198 |tunnel hdr||Simplemux hdr|IP packet||Simplemux hdr|IP packet||...| 200 1.3. Benefits of multiplexing 202 The benefits of multiplexing are: 204 - Tunneling a number of packets together. If a number of packets 205 have to be tunneled through a network segment, they can be 206 multiplexed and then sent together using a single external header. 207 This will avoid the need for adding a tunneling header to each of the 208 packets, thus reducing the overhead. 210 - Reduction of the amount of packets per second in the network. It 211 is desirable for two main reasons: first, network equipment has a 212 limitation in terms of the number of packets per second it can 213 manage, i.e. many devices are not able to send small packets back to 214 back due to processing delay. 216 - Bandwidth reduction. The presence of high rates of tiny packets 217 translates into an inefficient usage of network resources, so there 218 is a need for mechanisms able to reduce the overhead introduced by 219 low-efficiency flows. When combined with header compression, as done 220 in TCRTP [RFC4170] multiplexing may produce significant bandwidth 221 savings, which are interesting for network operators, since they may 222 alleviate the traffic load in their networks. 224 - Energy savings: a lower amount of packets per second will reduce 225 energy consumption in network equipment since, according to [Bolla], 226 internal packet processing engines and switching fabric require 60% 227 and 18% of the power consumption of high-end routers respectively. 228 Thus, reducing the number of packets to be managed and switched will 229 reduce the overall energy consumption. The measurements deployed in 230 [Chabarek]on commercial routers corroborate this. A study using 231 different packet sizes was presented, and the tests with big packets 232 showed that energy consumption gets reduced, since a non-negligible 233 amount of energy is associated to header processing tasks, and not 234 only to the sending of the packet itself. 236 2. Description of the scenario 238 Simplemux works between a pair of machines. It creates a tunnel 239 between an "ingress" and an "egress". They MAY be the endpoints of 240 the communication, but they MAY also be middleboxes able to multiplex 241 packets belonging to different flows. Different mechanisms MAY be 242 used in order to classify flows according to some criteria (sharing a 243 common path, kind of service, etc.) and to select the flows to be 244 multiplexed and sent to the egress (see Figure 2). 246 +-------+ 247 | | +---------+ +---------+ 248 | | ---> |Simplemux| _ _ |Simplemux| --> 249 |classif| ---> | ingress | ===> ( ` )_ ===> | egress | --> 250 | | +---------+ ( Network `) +---------+ 251 | | --------------------> (_ (_ . _) _) -----------------> 252 +-------+ 253 <--------Simplemux--------> 255 Figure 2 257 3. Protocol description 259 A Simplemux packet consists of: 261 - An external header that is used as the tunneling header for the 262 whole packet. 264 - A series of pairs "Simplemux header" + "packet" of the multiplexed 265 protocol. 267 This is the scheme of a Simplemux packet: 269 |tun hdr||Simplemux hdr|packet||Simplemux hdr|packet||...| 271 The Simplemux header has two different forms: one for the "First 272 Simplemux header," and another one for the rest of the Simplemux 273 headers (called "Non-first Simplemux headers"): 275 o First Simplemux header (after the tunneling header, and before the 276 first multiplexed packet): 278 In order to allow the multiplexing of packets of any length, the 279 number of bytes expressing the length is variable, and a field called 280 "Length Extension" (LXT, one bit) is used to flag if the current byte 281 is the last one including length information. This is the structure 282 of a First Simplemux header: 284 |SPB(1 bit)|LXT(1 bit)|length (6 bits)||LXT(1 bit)|length (7 285 bits)||...||Protocol (8 bits)| 287 - Single Protocol Bit (SPB, one bit) only appears in the first 288 Simplemux header. It is set to 1 if all the multiplexed packets 289 belong to the same protocol (in this case, the "Protocol" field will 290 only appear in the first Simplemux header). It is set to 0 when each 291 packet MAY belong to a different protocol. 293 - Length Extension (LXT, one bit) is 0 if the current byte is the 294 last byte where the length of the first packet is included, and 1 in 295 other case. 297 - Length (LEN, 6, 13, 20, etc. bits): This is the length of the 298 multiplexed packet (in bytes), not including the length field. If 299 the length of the multiplexed packet is less than 64 bytes (less than 300 or equal to 63 bytes), the first LXT is set to 0 and the 6 bits of 301 the length field are the length of the multiplexed packet. If the 302 length of the multiplexed packet is equal or greater than 64 bytes, 303 additional bytes are added. The first bit of each of the added bytes 304 is the LXT. If LXT is set to 1, it means that there is an additional 305 byte for expressing the length. This allows to multiplex packets of 306 any length (see the next figures). 308 - Protocol (8 bits) is the Protocol field of the multiplexed packet, 309 according to IANA "Assigned Internet Protocol Numbers." 311 As an example, a First Simplemux header before a packet smaller than 312 64 (2^6) bytes would be 2 bytes long: 314 0 1 315 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |S|L| | | 318 |P|X| Length | Protocol | 319 |B|T| (6 bits) | (8 bits) | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 ^ 322 0 324 Figure 3 326 A First Simplemux header before a packet with a length greater or 327 equal to 64 bytes, and smaller than 8192 bytes (2^13) will be 3 bytes 328 long: 330 0 1 2 331 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |S|L| |L| | | 334 |P|X| Length 1 |X| Length 2 | Protocol | 335 |B|T| (6 bits) |T| (7 bits) | (8 bits) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 ^ ^ 338 1 0 340 Figure 4 342 In this case, the length of the packet will be the number expressed 343 by the concatenation of the bits of Length 1 - Length 2 (total 13 344 bits). Length 1 includes the 6 most significant bits and Length 2 345 the 7 less significant bits. 347 A First Simplemux header before a packet with a length greater of 348 equal to 8192 bytes, and smaller than 1048576 bytes (2^20) would be 4 349 bytes long: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 |S|L| |L| |L| | | 355 |P|X| Length 1 |X| Length 2 |X| Length 3 | Protocol | 356 |B|T| (6 bits) |T| (7 bits) |T| (7 bits) | (8 bits) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 ^ ^ ^ 359 1 1 0 361 Figure 5 363 In this case, the length of the packet will be the number expressed 364 by the concatenation of the bits of Length 1 - Length 2 - Length 3 365 (total 20 bits). Length 1 includes the 6 most significant bits and 366 Length 3 the less 7 significant bits. 368 More bytes can be added to the length if required, using the same 369 scheme: 1 LXT byte plus 7 bits for expressing the length. 371 o Subsequent (Non-first) Simplemux headers (before the other 372 packets): 374 The Non-first Simplemux headers also employ a format allowing the 375 multiplexing of packets of any length, so the number of bytes 376 expressing the length is variable, and the field Length Extension 377 (LXT, one bit) is used to flag if the current byte is the last one 378 including length information. This is the structure of a Non-first 379 Simplemux header: 381 |LXT(1 bit)|length (7 bits)||LXT(1 bit)|length (7 382 bits)||...||Protocol (8 bits, optional)| 384 - Length Extension (LXT, one bit) is 0 if the current byte is the 385 last byte where the length of the packet is included, and 1 in other 386 case. 388 - Length (LEN, 7, 14, 21, etc. bits): This is the length of the 389 multiplexed packet (in bytes), not including the length field. If 390 the length of the multiplexed packet is less than 128 bytes (less 391 than or equal to 127 bytes), LXT is set to 0 and the 7 bits of the 392 length field represent the length of the multiplexed packet. If the 393 length of the multiplexed packet is greater than 127 bytes, 394 additional bytes are added. The first bit of each of the added bytes 395 is the LXT. If LXT is set to 1, it means that there is an additional 396 byte for expressing the length. This allows to multiplex packets of 397 any length (see the next figures). 399 - Protocol (8 bits) is the Protocol field of the multiplexed packet, 400 according to IANA "Assigned Internet Protocol Numbers". It only 401 appears in Non-first headers if the Single Protocol Bit (SPB) of the 402 First Simplemux header is set to 1. 404 As an example, a Non-first Simplemux header before a packet smaller 405 than 128 bytes, when the protocol bit has been set to 0 in the first 406 header, would be 1 byte long: 408 0 409 0 1 2 3 4 5 6 7 410 +-+-+-+-+-+-+-+-+ 411 |L| | 412 |X| Length | 413 |T| (7 bits) | 414 +-+-+-+-+-+-+-+-+ 415 ^ 416 0 418 SPB = 0 in the first header 420 Figure 6 422 A Non-first Simplemux header before a packet witha a length greater 423 or equal to 128 bytes, and smaller than 16384 (2^14), when the 424 protocol bit has been set to 0 in the first header, will be 2 bytes 425 long: 427 0 1 428 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |L| |L| | 431 |X| Length 1 |X| Length 2 | 432 |T| (7 bits) |T| (7 bits) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 ^ ^ 435 1 0 437 SPB = 0 in the first header 439 Figure 7 441 A Non-first Simplemux header before a packet with a length greater or 442 equal to 16384 bytes, and smaller than 2097152 bytes (2^21), when the 443 protocol bit has been set to 0 in the first header, will be 3 bytes 444 long: 446 0 1 2 447 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |L| |L| |L| | 450 |X| Length 1 |X| Length 2 |X| Length 3 | 451 |T| (7 bits) |T| (7 bits) |T| (7 bits) | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 ^ ^ ^ 454 1 1 0 456 SPB = 0 in the first header 458 Figure 8 460 In this case, the length of the packet will be the number expressed 461 by the concatenation of the bits of Length 1 - Length 2 - Length 3 462 (total 21 bits). Length 1 includes the 7 most significant bits and 463 Length 3 the 7 less significant bits. 465 More bytes can be added to the length if required, using the same 466 scheme: 1 LXT byte plus 7 bits for expressing the length. 468 A Non-first Simplemux header before a packet smaller than 128 bytes, 469 when the protocol bit has been set to 1 in the first header, will be 470 2 bytes long: 472 0 1 473 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 |L| | | 476 |X| Length | Protocol | 477 |T| (7 bits) | (8 bits) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 ^ 480 0 482 SPB = 1 in the first header 484 Figure 9 486 A Non-first Simplemux header before a packet with a length greater or 487 equal to 128 bytes, and smaller than 16384 (2^14), when the protocol 488 bit has been set to 1 in the first header, will be 3 bytes long: 490 0 1 2 491 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 |L| |L| | | 494 |X| Length 1 |X| Length 2 | Protocol | 495 |T| (7 bits) |T| (7 bits) | (8 bits) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 ^ ^ 498 1 0 500 SPB = 1 in the first header 502 Figure 10 504 A Non-first Simplemux header before a packet with a length greater of 505 equal to 16384 bytes, and smaller than 2097152 bytes (2^21), when the 506 protocol bit has been set to 1 in the first header, will be 4 bytes 507 long: 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 |L| |L| |L| | | 513 |X| Length 1 |X| Length 2 |X| Length 3 | Protocol | 514 |T| (7 bits) |T| (7 bits) |T| (7 bits) | (8 bits) | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 ^ ^ ^ 517 1 1 0 519 SPB = 1 in the first header 521 Figure 11 523 In this case, the length of the packet will be the number expressed 524 by the concatenation of the bits of Length 1 - Length 2 - Length 3 525 (total 21 bits). Length 1 includes the 7 most significant bits and 526 Length 3 the 7 less significant bits. 528 More bytes can be added to the length if required, using the same 529 scheme: 1 LXT byte plus 7 bits for expressing the length. 531 These would be some examples of the whole bundles: 533 Case 1: All the packets belong to the same protocol: The first 534 Simplemux header would be 2 or 3 bytes (for usual packet sizes), and 535 the other Simplemux headers would be 1 or 2 bytes. For small packets 536 (< 128 bytes), the Simplemux header would only require one byte. 538 |tun||1|0|len|Protocol|pkt||0|len|pkt||1|len|0|len|pkt||...| 539 | | | | 540 v v v v 541 (6 bits) (7 bits) (14 bits) 543 |tun||1|1|len|0|len|Protocol|pkt||0|len|pkt||1|len|0|len|pkt||...| 544 | | | | | 545 v v v v v 546 (13 bits) (7 bits) (14 bits) 548 Figure 12 550 Case 2: Each packet may belong to a different protocol: All the 551 Simplemux headers would be 2 or 3 bytes (for usual packet sizes). 553 |tun||0|0|len|Prot|pkt||0|len|Prot|pkt||1|len|0|len|Prot|pkt||...| 554 | | | | 555 v v v v 556 (6 bits) (7 bits) (14 bits) 558 |tun||0|1|len|0|len|Prot|pkt||0|len|Prot|pkt||1|len|0|len|Prot|pkt||...| 559 | | | | | 560 v v v v v 561 (13 bits) (7 bits) (14 bits) 563 Figure 13 565 4. Acknowledgements 567 Jose Saldana was funded by the EU H2020 Wi-5 project (Grant Agreement 568 no: 644262). 570 5. IANA Considerations 572 A protocol number for Simplemux should be requested to IANA. 574 As a provisional solution for IP networks, the ingress and the egress 575 optimizers may agree on a UDP port, and use IP/UDP as the 576 multiplexing protocol. 578 6. Security Considerations 580 7. References 582 7.1. Normative References 584 [RFC1570] Simpson, W., Ed., "PPP LCP Extensions", RFC 1570, 585 DOI 10.17487/RFC1570, January 1994, 586 . 588 [RFC1692] Cameron, P., Crocker, D., Cohen, D., and J. Postel, 589 "Transport Multiplexing Protocol (TMux)", RFC 1692, 590 DOI 10.17487/RFC1692, August 1994, 591 . 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, 595 DOI 10.17487/RFC2119, March 1997, 596 . 598 [RFC3153] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", 599 RFC 3153, DOI 10.17487/RFC3153, August 2001, 600 . 602 [RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling 603 Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, 604 DOI 10.17487/RFC4170, November 2005, 605 . 607 7.2. Informative References 609 [Bolla] Bolla, R., Bruschi, R., Davoli, F., and F. Cucchietti, 610 "Energy Efficiency in the Future Internet: A Survey of 611 Existing Approaches and Trends in Energy-Aware Fixed 612 Network Infrastructures", IEEE Communications Surveys and 613 Tutorials vol.13, no.2, pp.223,244, 2011. 615 [Chabarek] 616 Chabarek, J., Sommers, J., Barford, P., Estan, C., Tsiang, 617 D., and S. Wright, "Power Awareness in Network Design and 618 Routing", INFOCOM 2008. The 27th Conference on Computer 619 Communications. IEEE pp.457,465, 2008. 621 Author's Address 623 Jose Saldana 624 University of Zaragoza 625 Dpt. IEC Ada Byron Building 626 Zaragoza 50018 627 Spain 629 Phone: +34 976 762 698 630 Email: jsaldana@unizar.es