idnits 2.17.1 draft-saldana-lisp-compress-mux-06.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 4, 2019) is 1881 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: September 5, 2019 University of Zaragoza 6 March 4, 2019 8 Header compression and multiplexing in LISP 9 draft-saldana-lisp-compress-mux-06 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 5, 2019. 42 Copyright Notice 44 Copyright (c) 2019 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 as e.g., instant messaging, M2M (Machine to Machine) 81 services sending collected data in sensor networks or IoT scenarios 82 using wireless links, also use small packets. 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 number 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 aggregating 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 separator includes a field expressing the length of the next packet. 210 In the present case, LISP is used as the tunneling protocol. 212 A port number different from 4341 should be used in the UDP header 213 preceding the LISP header, in order to indicate that the protocol 214 inside the LISP header is not IP but Simplemux. 216 +--+---+----+----+--+---+-------+----+--+---+-------+----+--+---+-------+ 217 |OH|UDP|LISP|Smux|IH|TrH|payload|Smux|IH|TrH|payload|Smux|IH|TrH|payload| 218 +--+---+----+----+--+---+-------+----+--+---+-------+----+--+---+-------+ 219 | | | | | 220 <---LISP----><------pkt #1------><------pkt #2------><------pkt #3------> 222 Figure 3: Structure of a LISP packet encapsulating three IP packets 223 separated with Simplemux 225 2.3. Header compression and multiplexing method 227 ROHC (RObust Header Compression [RFC5795]) is able to compress UDP/ 228 IP, ESP/IP and RTP/UDP/IP headers. It is a robust scheme developed 229 for header compression over links with high bit error rates, such as 230 wireless ones. It incorporates mechanisms for quick 231 resynchronization of the context, with an improved encoding scheme 232 for compressing the header fields that change. 234 Taking into account that the inner packets are tunneled with LISP, 235 header compression can be used in order to remove those fields that 236 are the same for every packet in a flow. 238 The "Protocol" field of Simplemux allows the possibility of 239 indicating that the packets are compressed with ROHC [RFC5795]. The 240 protocol number 142 is used for this, as defined in [RFC5858]. 242 +--+---+----+----+----+-------+----+----+-------+----+----+-------+ 243 |OH|UDP|LISP|Smux|RoHC|payload|Smux|RoHC|payload|Smux|RoHC|payload| 244 +--+---+----+----+----+-------+----+----+-------+----+----+-------+ 245 | | | | | 246 <---LISP----><-----pkt #1-----><-----pkt #2-----><-----pkt #3-----> 248 Figure 4: Structure of a LISP packet encapsulating three packets 249 compressed with ROHC separated with Simplemux 251 3. Acknowledgements 253 This work has been partially funded by the EU H2020 Wi-5 project 254 (Grant Agreement no: 644262), the Spanish Ministry of Economy and 255 Competitiveness project TIN2015-64770-R, in cooperation with the 256 European Regional Development Fund (TIN2016-76770-R) and Gobierno de 257 Aragon and FEDER "Construyendo Europa desde Aragon" (Research Group 258 T31_17R). 260 4. IANA Considerations 262 The present document proposes the use of a Simplemux separator after 263 the LISP header, so a port number different from 4341 should be used 264 in the UDP header preceding the LISP header. 266 5. Security Considerations 268 The mechanism proposed in the present draft has been developed in 269 such a way that packet aggregation and security can be simultaneously 270 applied to the same traffic flows, i.e. a single security header 271 could protect a number of packets belonging to different flows. 273 As a consequence, the overall efficiency could be improved, as the 274 number of security headers could be reduced from N (being N the 275 number of multiplexed packets) to 1. 277 The proposed mechanism could work in cooperation with LISP-Security 278 [I-D.ietf-lisp-sec]. 280 6. References 281 6.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 289 Header Compression (ROHC) Framework", RFC 5795, 290 DOI 10.17487/RFC5795, March 2010, 291 . 293 [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec 294 Extensions to Support Robust Header Compression over 295 IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010, 296 . 298 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 299 Locator/ID Separation Protocol (LISP)", RFC 6830, 300 DOI 10.17487/RFC6830, January 2013, 301 . 303 6.2. Informative References 305 [Efficiency] 306 Bolla, R., Bruschi, R., Davoli, F., and F. Cucchietti, 307 "Energy Efficiency in the Future Internet: A Survey of 308 Existing Approaches and Trends in Energy-Aware Fixed 309 Network Infrastructures", IEEE Communications Surveys and 310 Tutorials vol.13, no.2, pp.223,244, 2011. 312 [I-D.ietf-lisp-sec] 313 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 314 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 315 (work in progress), October 2017. 317 [I-D.saldana-tsvwg-simplemux] 318 Saldana, J., "Simplemux. A generic multiplexing protocol", 319 draft-saldana-tsvwg-simplemux-09 (work in progress), 320 January 2017. 322 [Power] Chabarek, J., Sommers, J., Barford, P., Estan, C., Tsiang, 323 D., and S. Wright, "Power Awareness in Network Design and 324 Routing", INFOCOM 2008. The 27th Conference on Computer 325 Communications. IEEE pp.457,465, 2008. 327 [Simplemux_CIT] 328 Saldana, J., Forcen, I., Fernandez-Navajas, J., and J. 329 Ruiz-Mas, "Improving Network Efficiency with Simplemux", 330 IEEE CIT 2015, International Conference on Computer and 331 Information Technology , pp. 446-453, 26-28 October 2015, 332 Liverpool, UK, 2015. 334 Authors' Addresses 336 Jose Saldana 337 University of Zaragoza 338 Dpt. IEC Ada Byron Building 339 Zaragoza 50018 340 Spain 342 Phone: +34 976 762 698 343 Email: jsaldana@unizar.es 345 Julian Fernandez Navajas 346 University of Zaragoza 347 Dpt. IEC Ada Byron Building 348 Zaragoza 50018 349 Spain 351 Phone: +34 976 761 963 352 Email: navajas@unizar.es 354 Jose Ruiz Mas 355 University of Zaragoza 356 Dpt. IEC Ada Byron Building 357 Zaragoza 50018 358 Spain 360 Phone: +34 976 762 158 361 Email: jruiz@unizar.es