idnits 2.17.1 draft-saldana-lisp-compress-mux-04.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 (March 2, 2018) is 2245 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 (-05) exists of draft-boucadair-lisp-v6-compact-header-04 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-14 == Outdated reference: A later version (-12) exists of draft-saldana-tsvwg-simplemux-06 Summary: 2 errors (**), 0 flaws (~~), 4 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: September 3, 2018 University of Zaragoza 6 March 2, 2018 8 Header compression and multiplexing in LISP 9 draft-saldana-lisp-compress-mux-04 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 September 3, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 Some methods have been proposed in order to reduce LISP's overhead, 97 with the aim of avoiding MTU issues, as e.g. 98 [I-D.boucadair-lisp-v6-compact-header]. 100 When a number of small packets are in the buffer of an ITR, having 101 the same ETR as destination, they can be sent together, sharing a 102 single LISP header, and simultaneously obtaining three benefits: a) 103 bandwidth savings; b) a reduction in the number of packets, which may 104 also be translated into c) a reduction of the overall energy 105 consumption of network equipment. According to [Efficiency] internal 106 packet processing engines and switching fabric require 60% and 18% of 107 the power consumption of high-end routers respectively. Thus, 108 reducing the number of packets to be managed will reduce the overall 109 energy consumption. The measurements deployed in [Power] on 110 commercial routers corroborate this fact: a study using different 111 packet sizes was presented, and the tests with big packets showed a 112 reduction of the energy consumption, since a certain amount of energy 113 is associated to header processing tasks, and not only to the sending 114 of the packet itself. 116 All in all, another trade-off appears: on the one hand, energy 117 consumption is increased in the two extremes due to header 118 compression processing; on the other hand, energy consumption is 119 reduced in the intermediate nodes because of the reduction of the 120 number of packets transmitted. This tradeoff should be explored more 121 deeply. 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 2. Native LISP and proposed solutions 131 A LISP encapsulated packet, as defined in [RFC6830], has the next 132 structure (Figure 1): 134 +--+---+----+--+---+-------+ 135 |OH|UDP|LISP|IH|TrH|payload| 136 +--+---+----+--+---+-------+ 137 | | | 138 <---LISP----><-----pkt-----> 140 Figure 1: Structure of a LISP encapsulated packet 142 Where each of the headers corresponds to: 144 o OH: The outer header containing RLOCs obtained from the ingress 145 router's EID-to-RLOC Cache. 147 o UDP Header, as required by [RFC6830]. The destination port MUST 148 be set to the IANA-assigned port value 4341. 150 o LISP-specific 8-octet header. 152 o IH is the Inner Header on the datagram received from the 153 originating host. The source and destination IP addresses are 154 EIDs. 156 o TrH: The Transport Header, i.e. a TCP, UDP or SCTP header. 158 Note that [RFC6830] defines "LISP Header" as a set including: 160 o the outer IPv4 or IPv6 header; 162 o a UDP header; 164 o a LISP-specific 8-octet header that follows the UDP header. 166 2.1. Basic multiplexing method 168 When a number of small packets (e.g. VoIP, TCP ACKs, etc.) are 169 stored in the output buffer of an ITR, it MAY be possible to send a 170 number of them into a single RLOC-space packet, thus reducing the 171 overhead and the number of packets at the same time. This may have 172 some additional benefits, as the reduction of the amount of packets 173 travelling between the ITR and the ETR. It may also result in a 174 reduction of the processing requirements in intermediate nodes, which 175 may be transalted into certain energy savings. 177 A very strightforward solution for multiplexing a number of EID-space 178 packets into a single RLOC-space one is to just concatenate a number 179 of IP packets after the LISP Header (see Figure 2). 181 One of the free bits in the LISP header should be used to flag the 182 fact that more than a single packet is included in the encapsulated 183 one. 185 +--+---+----+--+---+-------+--+---+-------+--+---+-------+ 186 |OH|UDP|LISP|IH|TrH|payload|IH|TrH|payload|IH|TrH|payload| 187 +--+---+----+--+---+-------+--+---+-------+--+---+-------+ 188 | | | | | 189 <---LISP----><---pkt #1----><----pkt #2---><----pkt #3---> 191 Figure 2: Structure of a LISP packet encapsulating three IP packets 193 When an ETR receives a packet with the indication that it contains 194 more than a single packet (this is achieved by using a port number 195 different from 4341 in the UDP header preceding the LISP header), it 196 first extracts all the content after the LISP header, and then it 197 uses the "Total Length" field of the Inner IP Header to know the 198 length of the first packet. Once extracted, it removes the packet 199 and assumes the next bytes correspond to the next IP Header, so it 200 can subsequently extract all the included packets. 202 2.2. Multiplexing method based on Simplemux 204 Simplemux [I-D.saldana-tsvwg-simplemux] is a simple multiplexing 205 protocol that allows the inclusion of a whole packet belonging to any 206 protocol ("tunneled packet") into any tunneling protocol. It 207 includes a Lenght field, expressing the length of the multiplexed 208 packet, and a Protocol field, expressing the protocol to which the 209 tunneled packet belongs. 211 If a Simplemux separator is placed after the LISP header, then a 212 number of packets can be included, taking into account that the 213 Simplemux separator includes a field expressing the length of the 214 next packet. In the present case, LISP is used as the tunneling 215 protocol. 217 A port number different from 4341 should be used in the UDP header 218 preceding the LISP header, in order to indicate that the protocol 219 inside the LISP header is not IP but Simplemux. 221 +--+---+----+----+--+---+-------+----+--+---+-------+----+--+---+-------+ 222 |OH|UDP|LISP|Smux|IH|TrH|payload|Smux|IH|TrH|payload|Smux|IH|TrH|payload| 223 +--+---+----+----+--+---+-------+----+--+---+-------+----+--+---+-------+ 224 | | | | | 225 <---LISP----><------pkt #1------><------pkt #2------><------pkt #3------> 227 Figure 3: Structure of a LISP packet encapsulating three IP packets 228 separated with Simplemux 230 2.3. Header compression and multiplexing method 232 ROHC (RObust Header Compression [RFC5795]) is able to compress UDP/ 233 IP, ESP/IP and RTP/UDP/IP headers. It is a robust scheme developed 234 for header compression over links with high bit error rates, such as 235 wireless ones. It incorporates mechanisms for quick 236 resynchronization of the context, with an improved encoding scheme 237 for compressing the header fields that change. 239 Taking into account that the inner packets are tunneled with LISP, 240 header compression can be used in order to remove those fields that 241 are the same for every packet in a flow. 243 The "Protocol" field of Simplemux allows the possibility of 244 indicating that the packets are compressed with ROHC [RFC5795]. The 245 protocol number 142 is used for this, as defined in [RFC5858]. 247 +--+---+----+----+----+-------+----+----+-------+----+----+-------+ 248 |OH|UDP|LISP|Smux|RoHC|payload|Smux|RoHC|payload|Smux|RoHC|payload| 249 +--+---+----+----+----+-------+----+----+-------+----+----+-------+ 250 | | | | | 251 <---LISP----><-----pkt #1-----><-----pkt #2-----><-----pkt #3-----> 253 Figure 4: Structure of a LISP packet encapsulating three packets 254 compressed with ROHC separated with Simplemux 256 3. Acknowledgements 258 This work has been partially funded by the EU H2020 Wi-5 project 259 (Grant Agreement no: 644262) and the Spanish Ministry of Economy and 260 Competitiveness project TIN2015-64770-R, in cooperation with the 261 European Regional Development Fund. 263 4. IANA Considerations 265 The present document proposes the use of a Simplemux separator after 266 the LISP header, so a port number different from 4341 should be used 267 in the UDP header preceding the LISP header. 269 5. Security Considerations 271 The mechanism proposed in the present draft has been developed in 272 such a way that packet aggregation and security can be simultaneously 273 applied to the same traffic flows, i.e. a single security header 274 could protect a number of packets belonging to different flows. 276 As a consequence, the overall efficiency could be improved, as the 277 number of security headers could be reduced from N (being N the 278 number of multiplexed packets) to 1. 280 The proposed mechanism could work in cooperation with LISP-Security 281 [I-D.ietf-lisp-sec]. 283 6. References 285 6.1. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 293 Header Compression (ROHC) Framework", RFC 5795, 294 DOI 10.17487/RFC5795, March 2010, 295 . 297 [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec 298 Extensions to Support Robust Header Compression over 299 IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010, 300 . 302 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 303 Locator/ID Separation Protocol (LISP)", RFC 6830, 304 DOI 10.17487/RFC6830, January 2013, 305 . 307 6.2. Informative References 309 [Efficiency] 310 Bolla, R., Bruschi, R., Davoli, F., and F. Cucchietti, 311 "Energy Efficiency in the Future Internet: A Survey of 312 Existing Approaches and Trends in Energy-Aware Fixed 313 Network Infrastructures", IEEE Communications Surveys and 314 Tutorials vol.13, no.2, pp.223,244, 2011. 316 [I-D.boucadair-lisp-v6-compact-header] 317 Boucadair, M. and C. Jacquenet, "A Compact LISP 318 Encapsulation Scheme to Transport IPv4 Packets over an 319 IPv6 Network", draft-boucadair-lisp-v6-compact-header-04 320 (work in progress), Dec 2016. 322 [I-D.ietf-lisp-sec] 323 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 324 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 325 (work in progress), October 2017. 327 [I-D.saldana-tsvwg-simplemux] 328 Saldana, J., "Simplemux. A generic multiplexing protocol", 329 draft-saldana-tsvwg-simplemux-06 (work in progress), 330 January 2017. 332 [Power] Chabarek, J., Sommers, J., Barford, P., Estan, C., Tsiang, 333 D., and S. Wright, "Power Awareness in Network Design and 334 Routing", INFOCOM 2008. The 27th Conference on Computer 335 Communications. IEEE pp.457,465, 2008. 337 [Simplemux_CIT] 338 Saldana, J., Forcen, I., Fernandez-Navajas, J., and J. 339 Ruiz-Mas, "Improving Network Efficiency with Simplemux", 340 IEEE CIT 2015, International Conference on Computer and 341 Information Technology , pp. 446-453, 26-28 October 2015, 342 Liverpool, UK, 2015. 344 Authors' Addresses 346 Jose Saldana 347 University of Zaragoza 348 Dpt. IEC Ada Byron Building 349 Zaragoza 50018 350 Spain 352 Phone: +34 976 762 698 353 Email: jsaldana@unizar.es 355 Julian Fernandez Navajas 356 University of Zaragoza 357 Dpt. IEC Ada Byron Building 358 Zaragoza 50018 359 Spain 361 Phone: +34 976 761 963 362 Email: navajas@unizar.es 364 Jose Ruiz Mas 365 University of Zaragoza 366 Dpt. IEC Ada Byron Building 367 Zaragoza 50018 368 Spain 370 Phone: +34 976 762 158 371 Email: jruiz@unizar.es