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

Abstract

   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.

Status of This Memo

   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 Notice

   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



Saldana, et al.         Expires November 5, 2016                [Page 1]


Internet-Draft                   CM-LISP                        May 2016


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Native LISP and proposed solutions  . . . . . . . . . . . . .   3
     2.1.  Basic multiplexing method . . . . . . . . . . . . . . . .   4
     2.2.  Multiplexing method based on Simplemux  . . . . . . . . .   5
     2.3.  Header compression and multiplexing method  . . . . . . .   5
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

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






Saldana, et al.         Expires November 5, 2016                [Page 2]


Internet-Draft                   CM-LISP                        May 2016


   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.

1.1.  Requirements Language

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

2.  Native LISP and proposed solutions

   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:




Saldana, et al.         Expires November 5, 2016                [Page 3]


Internet-Draft                   CM-LISP                        May 2016


   o  OH: The outer header containing RLOCs obtained from the ingress
      router's EID-to-RLOC Cache.

   o  UDP Header, as required by [RFC6830].  The destination port MUST
      be set to the IANA-assigned port value 4341.

   o  LISP-specific 8-octet header.

   o  IH is the Inner Header on the datagram received from the
      originating host.  The source and destination IP addresses are
      EIDs.

   o  TrH: The Transport Header, i.e. a TCP, UDP or SCTP header.

   Note that [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.

2.1.  Basic multiplexing method

   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



Saldana, et al.         Expires November 5, 2016                [Page 4]


Internet-Draft                   CM-LISP                        May 2016


   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.

2.2.  Multiplexing method based on Simplemux

   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

2.3.  Header compression and multiplexing method

   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.





Saldana, et al.         Expires November 5, 2016                [Page 5]


Internet-Draft                   CM-LISP                        May 2016


   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

3.  Acknowledgements

   Jose Saldana, Julian Fernandez Navajas and Jose Ruiz Mas were funded
   by the EU H2020 Wi-5 project (Grant Agreement no: 644262).

4.  IANA Considerations

   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.

5.  Security Considerations

   No security issues have been identified.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5795]  Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
              Header Compression (ROHC) Framework", RFC 5795,
              DOI 10.17487/RFC5795, March 2010,
              <http://www.rfc-editor.org/info/rfc5795>.

   [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,
              <http://www.rfc-editor.org/info/rfc5858>.





Saldana, et al.         Expires November 5, 2016                [Page 6]


Internet-Draft                   CM-LISP                        May 2016


   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <http://www.rfc-editor.org/info/rfc6830>.

6.2.  Informative References

   [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", draft-boucadair-lisp-v6-compact-header-01
              (work in progress), December 2015.

   [I-D.saldana-tsvwg-simplemux]
              Saldana, J., "Simplemux. A generic multiplexing protocol",
              draft-saldana-tsvwg-simplemux-02 (work in progress),
              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.

Authors' Addresses

   Jose Saldana
   University of Zaragoza
   Dpt. IEC Ada Byron Building
   Zaragoza  50018
   Spain

   Phone: +34 976 762 698
   Email: jsaldana@unizar.es




Saldana, et al.         Expires November 5, 2016                [Page 7]


Internet-Draft                   CM-LISP                        May 2016


   Julian Fernandez Navajas
   University of Zaragoza
   Dpt. IEC Ada Byron Building
   Zaragoza  50018
   Spain

   Phone: +34 976 761 963
   Email: navajas@unizar.es


   Jose Ruiz Mas
   University of Zaragoza
   Dpt. IEC Ada Byron Building
   Zaragoza  50018
   Spain

   Phone: +34 976 762 158
   Email: jruiz@unizar.es

































Saldana, et al.         Expires November 5, 2016                [Page 8]