Header compression and multiplexing in LISP

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 . 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. . 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 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 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.

A LISP encapsulated packet, as defined in , has the next structure ():

<-----pkt-----> ]]> Where each of the headers corresponds to: OH: The outer header containing RLOCs obtained from the ingress router's EID-to-RLOC Cache. UDP Header, as required by . The destination port MUST be set to the IANA-assigned port value 4341. LISP-specific 8-octet header. IH is the Inner Header on the datagram received from the originating host. The source and destination IP addresses are EIDs. TrH: The Transport Header, i.e. a TCP, UDP or SCTP header. Note that 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.

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 ). 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.

<---pkt #1----><----pkt #2---><----pkt #3---> ]]> 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 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.

<------pkt #1------><------pkt #2------><------pkt #3------> ]]>

Taking into account that the inner packets are tunneled with LISP, a header compresion method can be used (ROHC ), in order to remove those fields that are the same for every packet in a flow. ROHC (RObust Header Compression ) 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 . The protocol number 142 is used for this, as defined in .

<-----pkt #1-----><-----pkt #2-----><-----pkt #3-----> ]]>

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.