| Locator/ID Separation Protocol Working Group | J. Saldana |
| Internet-Draft | J. Fernandez Navajas |
| Intended status: Experimental | J. Ruiz Mas |
| Expires: November 5, 2016 | University of Zaragoza |
| May 4, 2016 |
Header compression and multiplexing in LISP
draft-saldana-lisp-compress-mux-00
When small payloads are transmitted through a packet-switched network, the resulting overhead may result significant. This is stressed in the case of LISP, where a number of headers are prepended to a packet, as new headers have to be added to each packet.
This document proposes to send together a number of small packets, which are in the buffer of a ITR, having the same ETR as destination, into a single packet. Therefore, they will share a single LISP header, and therefore bandwidth savings can be obtained, and a reduction in the overall number of packets sent to the network can be achieved.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
When small payloads are transmitted through a packet-switched network, the resulting overhead may result significant. This is stressed in the case of tunneling protocols, where a number of headers are prepended to a packet.
The rate of small packets present in the Internet is significant [Simplemux_CIT]. First, TCP Acknowledgements (ACKs), which may have no payload, are sent in every TCP connection. In addition real-time services (VoIP, videoconferencing, telemedicine, video surveillance, online gaming, etc.) with interactivity demands may generate a traffic profile consisting of high rates of small packets, which are necessary in order to transmit frequent updates between the two extremes of the communication. In addition, some other services also use small packets as e.g., instant messaging, M2M packets sending collected data in sensor networks or IoT scenarios using wireless or satellite links.
In the case of LISP, this overhead may be stressed. As an example, an IPv4 TCP ACK (40 bytes), with standard LISP over IPv4 requires 76 bytes (96 if IPv6 is used by one of the IP headers). Or an RTP packet with e.g. 20 bytes of payload, using standard LISP over IPv4, requires 96 bytes (116 if IPv6 is used in one of the IP headers).
Some methods have been proposed in order to reduce LISP's overhead, with the aim of avoiding MTU issues, as e.g. [I-D.boucadair-lisp-v6-compact-header].
When a number of small packets are in the buffer of a ITR, having the same ETR as destination, they can be sent together, sharing a single LISP header, and therefore obtaining three benefits: bandwidth savings, reduction in the number of packets, which may also be translated into a reduction of the overall energy consumption of network equipment. According to [Efficiency] internal packet processing engines and switching fabric require 60% and 18% of the power consumption of high-end routers respectively. Thus, reducing the number of packets to be managed will reduce the overall energy consumption. The measurements deployed in [Power] on commercial routers corroborate this: a study using different packet sizes was presented, and the tests with big packets showed a reduction of the energy consumption, since a certain amount of energy is associated to header processing tasks, and not only to the sending of the packet itself.
All in all, another trade-off appears: on the one hand, energy consumption is increased in the two extremes due to header compression processing; on the other hand, energy consumption is reduced in the intermediate nodes because of the reduction of the number of packets transmitted. This tradeoff should be explored more deeply.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
A LISP encapsulated packet, as defined in [RFC6830], has the next structure (Figure 1):
+--+---+----+--+---+-------+
|OH|UDP|LISP|IH|TrH|payload|
+--+---+----+--+---+-------+
| | |
<---LISP----><-----pkt----->
Figure 1: Structure of a LISP encapsulated packet
Where each of the headers corresponds to:
[RFC6830] defines "LISP Header" as a set including: the outer IPv4 or IPv6 header; a UDP header; and a LISP-specific 8-octet header that follows the UDP header.
Note that
When a number of small packets (e.g. VoIP, TCP ACKs, etc.) are stored in the output buffer of an ITR, it MAY be possible to send a number of them into a single RLOC-space packet, thus reducing the overhead and the number of packets at the same time. This may have some additional benefits as the reduction of the amount of packets travelling between the ITR and the ETR may result in a reduction of the processing requirements in intermediate nodes, which may be transalted into certain energy savings.
A very strightforward solution for multiplexing a number of EID-space packets into a single RLOC-space one is to just concatenate a number of IP packets after the LISP Header (see Figure 2).
One of the free bits in the LISP header should be used to flag the fact that more than a single packet is included in the encapsulated one.
+--+---+----+--+---+-------+--+---+-------+--+---+-------+
|OH|UDP|LISP|IH|TrH|payload|IH|TrH|payload|IH|TrH|payload|
+--+---+----+--+---+-------+--+---+-------+--+---+-------+
| | | | |
<---LISP----><---pkt #1----><----pkt #2---><----pkt #3--->
Figure 2: Structure of a LISP packet encapsulating three IP packets
When an ETR receives a packet with the indication that it contains more than a single packet (this is achieved by using a port number different from 4341 in the UDP header preceding the LISP header), it first extracts all the content after the LISP header, and then it uses the "Total Length" field of the Inner IP Header to know the length of the first packet. Once extracted, it removes the packet and assumes the next bytes correspond to the next IP Header, so it can subsequently extract all the included packets.
If a Simplemux separator is placed after the LISP header, then a number of packets can be included, taking into account that the Simplemux separator includes a field expressing the length of the next packet.
Simplemux [I-D.saldana-tsvwg-simplemux] is a simple multiplexing protocol that allows the inclusion of a whole packet belonging to any protocol (tunneled packet) into any tunneling protocol. It includes a Lenght field, expressing the length of the multiplexed packet, and a Protocol field, expressing the protocol to which the tunneled packet belongs. In the present case, LISP is used as the tunneling protocol.
In this case, a port number different from 4341 should be used in the UDP header preceding the LISP header, in order to indicate that the protocol inside the LISP header is not IP but Simplemux.
+--+---+----+----+--+---+-------+----+--+---+-------+----+--+---+-------+
|OH|UDP|LISP|Smux|IH|TrH|payload|Smux|IH|TrH|payload|Smux|IH|TrH|payload|
+--+---+----+----+--+---+-------+----+--+---+-------+----+--+---+-------+
| | | | |
<---LISP----><------pkt #1------><------pkt #2------><------pkt #3------>
Figure 3: Structure of a LISP packet encapsulating three IP packets separated with Simplemux
Taking into account that the inner packets are tunneled with LISP, a header compresion method can be used (ROHC [RFC5795]), in order to remove those fields that are the same for every packet in a flow.
ROHC (RObust Header Compression [RFC5795]) is able to compress UDP/IP, ESP/IP and RTP/UDP/IP headers. It is a robust scheme developed for header compression over links with high bit error rate, such as wireless ones. It incorporates mechanisms for quick resynchronization of the context, with an improved encoding scheme for compressing the header fields that change dynamically.
The "Protocol" field of Simplemux allows the possibility of indicating that the packets are compressed with ROHC [RFC5795]. The protocol number 142 is used for this, as defined in [RFC5858].
+--+---+----+----+----+-------+----+----+-------+----+----+-------+
|OH|UDP|LISP|Smux|RoHC|payload|Smux|RoHC|payload|Smux|RoHC|payload|
+--+---+----+----+----+-------+----+----+-------+----+----+-------+
| | | | |
<---LISP----><-----pkt #1-----><-----pkt #2-----><-----pkt #3----->
Figure 4: Structure of a LISP packet encapsulating three packets compressed with ROHC separated with Simplemux
Jose Saldana, Julian Fernandez Navajas and Jose Ruiz Mas were funded by the EU H2020 Wi-5 project (Grant Agreement no: 644262).
The present document proposes the use of a Simplemux separator after the LISP header, so a port number different from 4341 should be used in the UDP header preceding the LISP header.
No security issues have been identified.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC5795] | Sandlund, K., Pelletier, G. and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010. |
| [RFC5858] | Ertekin, E., Christou, C. and C. Bormann, "IPsec Extensions to Support Robust Header Compression over IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010. |
| [RFC6830] | Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013. |
| [Efficiency] | Bolla, R., Bruschi, R., Davoli, F. and F. Cucchietti, "Energy Efficiency in the Future Internet: A Survey of Existing Approaches and Trends in Energy-Aware Fixed Network Infrastructures", IEEE Communications Surveys and Tutorials vol.13, no.2, pp.223,244, 2011. |
| [I-D.boucadair-lisp-v6-compact-header] | Boucadair, M. and C. Jacquenet, "A Compact LISP Encapsulation Scheme to Transport IPv4 Packets over an IPv6 Network", Internet-Draft draft-boucadair-lisp-v6-compact-header-01, December 2015. |
| [I-D.saldana-tsvwg-simplemux] | Saldana, J., "Simplemux. A generic multiplexing protocol", Internet-Draft draft-saldana-tsvwg-simplemux-02, January 2015. |
| [Power] | Chabarek, J., Sommers, J., Barford, P., Estan, C., Tsiang, D. and S. Wright, "Power Awareness in Network Design and Routing", INFOCOM 2008. The 27th Conference on Computer Communications. IEEE pp.457,465, 2008. |
| [Simplemux_CIT] | Saldana, J., Forcen, I., Fernandez-Navajas, J. and J. Ruiz-Mas, "Improving Network Efficiency with Simplemux", IEEE CIT 2015, International Conference on Computer and Information Technology , pp. 446-453, 26-28 October 2015, Liverpool, UK, 2015. |