idnits 2.17.1 draft-saldana-lisp-compress-mux-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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 3, 2018) is 2056 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-15 == Outdated reference: A later version (-12) exists of draft-saldana-tsvwg-simplemux-09 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Locator/ID Separation Protocol Working Group J. Saldana 3 Internet-Draft J. Fernandez Navajas 4 Intended status: Experimental J. Ruiz Mas 5 Expires: March 7, 2019 University of Zaragoza 6 September 3, 2018 8 Header compression and multiplexing in LISP 9 draft-saldana-lisp-compress-mux-05 11 Abstract 13 When small payloads are transmitted through a packet-switched 14 network, the resulting overhead may result significant. This is 15 stressed in the case of LISP, where a number of headers have to be 16 added to each packet. 18 This document proposes a way to send together, into a single packet, 19 a number of small packets, which are in the buffer of a ITR, having 20 the same ETR as destination. This way, they can share a single LISP 21 header, and therefore bandwidth savings can be obtained, and a 22 reduction in the overall number of packets sent to the network can be 23 achieved. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 7, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Native LISP and proposed solutions . . . . . . . . . . . . . 3 59 2.1. Basic multiplexing method . . . . . . . . . . . . . . . . 4 60 2.2. Multiplexing method based on Simplemux . . . . . . . . . 5 61 2.3. Header compression and multiplexing method . . . . . . . 5 62 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 6.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 The rate of small packets present in the Internet is significant 73 [Simplemux_CIT]. First, TCP Acknowledgements (ACKs), which may have 74 no payload, are sent in every TCP connection. In addition some 75 services with real-time and interactivity constraints (VoIP, 76 videoconferencing, telemedicine, video surveillance, online gaming, 77 etc.) generate a traffic profile consisting of high rates of small 78 packets, which are necessary in order to transmit frequent updates 79 between the two extremes of the communication. In addition, some 80 other services also use small packets as e.g., instant messaging, M2M 81 (Machine to Machine) services sending collected data in sensor 82 networks or IoT scenarios using wireless links. 84 When small payloads are transmitted through a packet-switched 85 network, the resulting overhead may result significant. This is more 86 signifcant in the case of tunneling protocols, where a number of 87 headers are prepended to a packet. 89 In the case of LISP, this overhead may be further stressed. As an 90 example, an IPv4 TCP ACK (40 bytes), sent with standard LISP over 91 IPv4 requires 76 bytes (96 if IPv6 is used by one of the IP headers). 92 Or an RTP packet with e.g. 20 bytes of payload, using standard LISP 93 over IPv4, requires 96 bytes (116 if IPv6 is used in one of the IP 94 headers). 96 When a number of small packets are in the buffer of an ITR, having 97 the same ETR as destination, they can be sent together, sharing a 98 single LISP header, and simultaneously obtaining three benefits: a) 99 bandwidth savings; b) a reduction in the number of packets, which may 100 also be translated into c) a reduction of the overall energy 101 consumption of network equipment. According to [Efficiency] internal 102 packet processing engines and switching fabric require 60% and 18% of 103 the power consumption of high-end routers respectively. Thus, 104 reducing the number of packets to be managed will reduce the overall 105 energy consumption. The measurements deployed in [Power] on 106 commercial routers corroborate this fact: a study using different 107 packet sizes was presented, and the tests with big packets showed a 108 reduction of the energy consumption, since a certain amount of energy 109 is associated to header processing tasks, and not only to the sending 110 of the packet itself. 112 All in all, another trade-off appears: on the one hand, energy 113 consumption is increased in the two extremes due to header 114 compression processing; on the other hand, energy consumption is 115 reduced in the intermediate nodes because of the reduction of the 116 number of packets transmitted. This tradeoff should be explored more 117 deeply. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. Native LISP and proposed solutions 127 A LISP encapsulated packet, as defined in [RFC6830], has the next 128 structure (Figure 1): 130 +--+---+----+--+---+-------+ 131 |OH|UDP|LISP|IH|TrH|payload| 132 +--+---+----+--+---+-------+ 133 | | | 134 <---LISP----><-----pkt-----> 136 Figure 1: Structure of a LISP encapsulated packet 138 Where each of the headers corresponds to: 140 o OH: The outer header containing RLOCs obtained from the ingress 141 router's EID-to-RLOC Cache. 143 o UDP Header, as required by [RFC6830]. The destination port MUST 144 be set to the IANA-assigned port value 4341. 146 o LISP-specific 8-octet header. 148 o IH is the Inner Header on the datagram received from the 149 originating host. The source and destination IP addresses are 150 EIDs. 152 o TrH: The Transport Header, i.e. a TCP, UDP or SCTP header. 154 Note that [RFC6830] defines "LISP Header" as a set including: 156 o the outer IPv4 or IPv6 header; 158 o a UDP header; 160 o a LISP-specific 8-octet header that follows the UDP header. 162 2.1. Basic multiplexing method 164 When a number of small packets (e.g. VoIP, TCP ACKs, etc.) are 165 stored in the output buffer of an ITR, it MAY be possible to send a 166 number of them into a single RLOC-space packet, thus reducing the 167 overhead and the number of packets at the same time. This may have 168 some additional benefits, as the reduction of the amount of packets 169 travelling between the ITR and the ETR. It may also result in a 170 reduction of the processing requirements in intermediate nodes, which 171 may be transalted into certain energy savings. 173 A very strightforward solution for multiplexing a number of EID-space 174 packets into a single RLOC-space one is to just concatenate a number 175 of IP packets after the LISP Header (see Figure 2). 177 One of the free bits in the LISP header should be used to flag the 178 fact that more than a single packet is included in the encapsulated 179 one. 181 +--+---+----+--+---+-------+--+---+-------+--+---+-------+ 182 |OH|UDP|LISP|IH|TrH|payload|IH|TrH|payload|IH|TrH|payload| 183 +--+---+----+--+---+-------+--+---+-------+--+---+-------+ 184 | | | | | 185 <---LISP----><---pkt #1----><----pkt #2---><----pkt #3---> 187 Figure 2: Structure of a LISP packet encapsulating three IP packets 189 When an ETR receives a packet with the indication that it contains 190 more than a single packet (this is achieved by using a port number 191 different from 4341 in the UDP header preceding the LISP header), it 192 first extracts all the content after the LISP header, and then it 193 uses the "Total Length" field of the Inner IP Header to know the 194 length of the first packet. Once extracted, it removes the packet 195 and assumes the next bytes correspond to the next IP Header, so it 196 can subsequently extract all the included packets. 198 2.2. Multiplexing method based on Simplemux 200 Simplemux [I-D.saldana-tsvwg-simplemux] is a simple multiplexing 201 protocol that allows the inclusion of a whole packet belonging to any 202 protocol ("tunneled packet") into any tunneling protocol. It 203 includes a Lenght field, expressing the length of the multiplexed 204 packet, and a Protocol field, expressing the protocol to which the 205 tunneled packet belongs. 207 If a Simplemux separator is placed after the LISP header, then a 208 number of packets can be included, taking into account that the 209 Simplemux separator includes a field expressing the length of the 210 next packet. In the present case, LISP is used as the tunneling 211 protocol. 213 A port number different from 4341 should be used in the UDP header 214 preceding the LISP header, in order to indicate that the protocol 215 inside the LISP header is not IP but Simplemux. 217 +--+---+----+----+--+---+-------+----+--+---+-------+----+--+---+-------+ 218 |OH|UDP|LISP|Smux|IH|TrH|payload|Smux|IH|TrH|payload|Smux|IH|TrH|payload| 219 +--+---+----+----+--+---+-------+----+--+---+-------+----+--+---+-------+ 220 | | | | | 221 <---LISP----><------pkt #1------><------pkt #2------><------pkt #3------> 223 Figure 3: Structure of a LISP packet encapsulating three IP packets 224 separated with Simplemux 226 2.3. Header compression and multiplexing method 228 ROHC (RObust Header Compression [RFC5795]) is able to compress UDP/ 229 IP, ESP/IP and RTP/UDP/IP headers. It is a robust scheme developed 230 for header compression over links with high bit error rates, such as 231 wireless ones. It incorporates mechanisms for quick 232 resynchronization of the context, with an improved encoding scheme 233 for compressing the header fields that change. 235 Taking into account that the inner packets are tunneled with LISP, 236 header compression can be used in order to remove those fields that 237 are the same for every packet in a flow. 239 The "Protocol" field of Simplemux allows the possibility of 240 indicating that the packets are compressed with ROHC [RFC5795]. The 241 protocol number 142 is used for this, as defined in [RFC5858]. 243 +--+---+----+----+----+-------+----+----+-------+----+----+-------+ 244 |OH|UDP|LISP|Smux|RoHC|payload|Smux|RoHC|payload|Smux|RoHC|payload| 245 +--+---+----+----+----+-------+----+----+-------+----+----+-------+ 246 | | | | | 247 <---LISP----><-----pkt #1-----><-----pkt #2-----><-----pkt #3-----> 249 Figure 4: Structure of a LISP packet encapsulating three packets 250 compressed with ROHC separated with Simplemux 252 3. Acknowledgements 254 This work has been partially funded by the EU H2020 Wi-5 project 255 (Grant Agreement no: 644262), the Spanish Ministry of Economy and 256 Competitiveness project TIN2015-64770-R, in cooperation with the 257 European Regional Development Fund (TIN2016-76770-R) and Gobierno de 258 Aragon and FEDER "Construyendo Europa desde Aragon" (Research Group 259 T31_17R). 261 4. IANA Considerations 263 The present document proposes the use of a Simplemux separator after 264 the LISP header, so a port number different from 4341 should be used 265 in the UDP header preceding the LISP header. 267 5. Security Considerations 269 The mechanism proposed in the present draft has been developed in 270 such a way that packet aggregation and security can be simultaneously 271 applied to the same traffic flows, i.e. a single security header 272 could protect a number of packets belonging to different flows. 274 As a consequence, the overall efficiency could be improved, as the 275 number of security headers could be reduced from N (being N the 276 number of multiplexed packets) to 1. 278 The proposed mechanism could work in cooperation with LISP-Security 279 [I-D.ietf-lisp-sec]. 281 6. References 282 6.1. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 290 Header Compression (ROHC) Framework", RFC 5795, 291 DOI 10.17487/RFC5795, March 2010, 292 . 294 [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec 295 Extensions to Support Robust Header Compression over 296 IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010, 297 . 299 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 300 Locator/ID Separation Protocol (LISP)", RFC 6830, 301 DOI 10.17487/RFC6830, January 2013, 302 . 304 6.2. Informative References 306 [Efficiency] 307 Bolla, R., Bruschi, R., Davoli, F., and F. Cucchietti, 308 "Energy Efficiency in the Future Internet: A Survey of 309 Existing Approaches and Trends in Energy-Aware Fixed 310 Network Infrastructures", IEEE Communications Surveys and 311 Tutorials vol.13, no.2, pp.223,244, 2011. 313 [I-D.ietf-lisp-sec] 314 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 315 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 316 (work in progress), October 2017. 318 [I-D.saldana-tsvwg-simplemux] 319 Saldana, J., "Simplemux. A generic multiplexing protocol", 320 draft-saldana-tsvwg-simplemux-09 (work in progress), 321 January 2017. 323 [Power] Chabarek, J., Sommers, J., Barford, P., Estan, C., Tsiang, 324 D., and S. Wright, "Power Awareness in Network Design and 325 Routing", INFOCOM 2008. The 27th Conference on Computer 326 Communications. IEEE pp.457,465, 2008. 328 [Simplemux_CIT] 329 Saldana, J., Forcen, I., Fernandez-Navajas, J., and J. 330 Ruiz-Mas, "Improving Network Efficiency with Simplemux", 331 IEEE CIT 2015, International Conference on Computer and 332 Information Technology , pp. 446-453, 26-28 October 2015, 333 Liverpool, UK, 2015. 335 Authors' Addresses 337 Jose Saldana 338 University of Zaragoza 339 Dpt. IEC Ada Byron Building 340 Zaragoza 50018 341 Spain 343 Phone: +34 976 762 698 344 Email: jsaldana@unizar.es 346 Julian Fernandez Navajas 347 University of Zaragoza 348 Dpt. IEC Ada Byron Building 349 Zaragoza 50018 350 Spain 352 Phone: +34 976 761 963 353 Email: navajas@unizar.es 355 Jose Ruiz Mas 356 University of Zaragoza 357 Dpt. IEC Ada Byron Building 358 Zaragoza 50018 359 Spain 361 Phone: +34 976 762 158 362 Email: jruiz@unizar.es