FM-Delta: Fault Management Packet Compression

TL;DR

FM-Delta introduces a hardware-friendly delta encoding method that compresses Fault Management messages by a factor of 2.6, significantly reducing on-chip memory requirements in communication network switches and routers.

Contribution

The paper presents FM-Delta, a novel delta encoding algorithm for FM messages that achieves high compression with low implementation complexity.

Findings

Compression ratio of 2.6 achieved by FM-Delta

Close to zlib compression performance

Reduces on-chip memory needs significantly

Abstract

Fault Management (FM) is a cardinal feature in communication networks. One of the most common FM approaches is to use periodic keepalive messages. Hence, switches and routers are required to transmit a large number of FM messages periodically, requiring a hardware-based packet generator that periodically transmits a set of messages that are stored in an expensive on-chip memory. With the rapid growth of carrier networks, and as 5G technologies emerge, the number of users and the traffic rates are expected to significantly increase over the next few years. Consequently, we expect the on-chip memories used for FM to become a costly component in switch and router chips. We introduce a novel approach in which FM messages are stored in compressed form in the on-chip memory, allowing to significantly reduce the memory size. We present FM-Delta, a simple hardware-friendly delta encoding algorithm that allows FM messages to be compressed by a factor of 2.6. We show that this compression ratio is very close to the results of the zlib compression library, which requires much higher implementation complexity.

Full text

I Introduction

I-A Background

Network devices, such as switches and routers, are often required to transmit control-plane messages. The ability to generate and transmit messages has been recognized as an essential building block in network devices, not only in conventional networks, but also in Software-Defined Networks (e.g., [2]). Specifically, the ability to generate packets is important in the context of Fault Management (FM).

Fault detection is essential in large-scale networks, enabling fast recovery and effective troubleshooting; it is one of the key components in Operations, Administration, and Maintenance (OAM) [3]. FM is typically implemented as a combination of proactive and reactive mechanisms for detecting failures. Some of the most commonly deployed FM protocols (e.g.,  [4, 5, 6]) are implemented using periodic keepalive messages; a fault is detected when no keepalive messages are received from a given source for a given period of time.

I-B FM Scaling

The scaling problem of storing FM messages is a real-life problem that some of the authors of this paper encountered while designing packet processor silicons. A switch or a router that runs an FM protocol periodically transmits FM messages. The rate of FM messages varies from 1 packet every ten minutes to 300 packets per second per service [4, 5]. Typical carrier Ethernet devices support tens of thousands of services (e.g., 16k in [7] and 64k in [8]). Due to these large scales, typical devices do not provide FM support at the highest rate for all services simultaneously. As 5G technologies evolve, network devices will be required to support a larger number of services at a higher bandwidth. Thus, fault detection will be expected with a low detection time, implying a high rate of FM messages. Hence, we expect these scales to continuously increase in the next few years.

Example. The rate of traffic that a network device is expected to generate for 64k services, assuming the FM message length is roughly 100B [4], and assuming 300 packets per second per service [4], is $64k\times 300\times 100B\cong 16~{}Gbps$. Such high traffic rates cannot be handled by the device’s software layer, and thus must be implemented in the device’s hardware. A typical implementation (e.g., [9]) uses a hardware engine and an on-chip memory; the engine periodically reads the messages stored in the memory and transmits them to the network. In this case the required memory space for 64k services is $64k\times 100B\cong 6.4~{}MB$. This is a very significant size for an on-chip memory, consuming an expensive area of roughly 18 $mm^{2}$ in a 28nm process. As a point of reference, the entire on-chip packet memory of a typical switch is on the order of a few megabytes, e.g., 12 MB in [10].

This example illustrates that as carrier and mobile backhaul networks evolve, the significant size of the FM on-chip memory may become infeasible.

I-C FM Packet Compression in a Nutshell

We argue that if FM packets are compressed when stored in the memory, then the expensive on-chip memory can be significantly reduced.

In our approach FM packets are compressed offline, and stored in compressed form in an on-chip memory. Each packet is decompressed by the hardware packet generation engine before it is transmitted to the network. Notably, packets are in compressed form only when stored in memory, and are decompressed before transmission, making the compression transparent to the network.

Why do we focus on FM messages? The solution we propose relies on three properties that are unique to the problem at hand: (i) the entropy of the FM packets stored in the memory is low, as they share common properties, (ii) the FM packet memory is accessed sequentially, since all packets are sent periodically, and (iii) we can determine the order of the FM packets in the memory.111In the FM-Delta system we present we have full control of the order in which packets are stored in the memory, and thus the order in which packets are accessed and decompressed. These three properties significantly improve the effectiveness of the compression.

I-D Related Work

Data compression has been analyzed in the context of network switches and routers, e.g., [11, 12]. Specifically, data-plane packet compression has been widely discussed and analyzed in the literature, e.g., [13, 14]. For example, packet compression is widely used in the Hypertext Transfer Protocol (HTTP) [15]. It has been shown that HTTP compression can be very effective [16], in some cases reducing the data to 20% of its original size. However, it has been shown [13] that packet compression is ineffective for random internet traffic, as this traffic typically has high entropy, and is often already compressed or encrypted. In this paper we focus on control-plane packet compression, and present a use case in which packet compression is highly effective.

I-E Contributions

The contributions of this paper are as follows:

• •

We present a novel approach that uses packet compression to reduce the size of the on-chip memory used in Fault Management (FM) message transmission.

• •

We introduce FM-Delta, a simple delta encoding algorithm that can easily be implemented in hardware, and present a high-level design of a system that uses FM-Delta.

• •

We evaluated the algorithm over a synthetically generated FM packet database, and show that it offers a compression ratio that is comparable to state-of-the-art compression algorithms, such as Lempel-Ziv (LZ).222It is important to note that known LZ implementations (such as zlib [17]) are unlikely to be realizable in the low-level hardware setup of interest here, due to their significant processing and memory requirements. The FM packet database that we used in our experiments is publicly available [18].

\widowpenalties

1 10000

II A System Design

II-A Overview

Fig. 1 illustrates the design of a system that uses FM-Delta to periodically generate FM packets. The system consists of two main components:

• •

Software module – responsible for compressing the FM packets and storing them in the on-chip memory of the packet generation engine. The compression procedure is performed offline. When an FM packet needs to be added to the FM packet database, or removed from it, the software layer invokes an insert or a remove operation, instructing the packet generation engine to perform an incremental update in the FM database.

• •

Packet generation engine – this hardware module sequentially reads the packets from the on-chip FM packet memory, decompresses them in real-time, and transmits them to the network.

II-B Compression Algorithm

We introduce FM-Delta, a simple delta encoding algorithm that we designed and implemented.

FM-Delta. We present an outline of the FM-Delta algorithm. Given a sequence of N uncompressed packets, the compressed packets are represented as follows.

The first packet is represented in uncompressed form, as shown in Fig. 2.

The $i^{th}$ packet, for $i\geq 2$, is compressed, as shown in Fig. 3.

The compressed packet consists of the following fields (Fig. 3):

• •

Length – represents the length in bytes of the original (uncompressed) packet.

• •

Delta Bitmap – indicates the differences between packet $i$ and packet $i-1$. Every packet is divided into equal-sized words, and each bit in the bitmap indicates whether the respective word in the current packet is equal to the corresponding word in the previous packet. The word size is a parameter of the algorithm. Section III discusses the effectiveness of the algorithm with various word sizes.

• •

Values – the values of the words that differ from the previous packet.

The decompression algorithm is presented in Fig. 4.

Common (de)compression algorithms, such as Lempel-Ziv [19] are not hardware-friendly, as they require a complex iterative indirection over a sliding window. In FM-Delta, every packet is decompressed by comparing it to the previous (decompressed) packet using the Delta Bitmap. This simple comparison does not require an iterative procedure, and thus all the words of the packet can be compared (decompressed) in parallel, making FM-Delta a silicon-friendly algorithm.

II-C Insertion and Removal

As described above, the packet database is compressed offline, and accessed by the chip in real-time. An essential question is how the packet database is updated, i.e., how a new packet can be added to the database, or how a packet can be removed from it.

One approach that allows simple insertion and removal is by using a linked list. Each compressed packet in the memory is followed by a pointer that points to the location of the next packet in memory. The linked list approach is simple, but requires some memory overhead for the next pointers, and also may be inefficient due to fragmentation.

We suggest a more efficient approach that allows for simple insertion and removal of packets when using FM-Delta. In this approach (Fig. 5) packets are stored contiguously in the memory. The packet generation engine proceeds by a read-decompress-write procedure; every packet is read from memory, decompressed, and then written back to the memory. There is a cache that stores the previous packet, which enables the engine to decompress the current packet using FM-Delta.

Removal

Assume that we have $N$ compressed packets in the memory, denoted by $P_{1},P_{2},\ldots,P_{N}$, and we want to remove a packet $P_{k}$ from the database. Removing the $k^{th}$ packet from the database includes two operations that need to take place atomically: (i) removing the $k^{th}$ packet from the memory, and (ii) updating the $(k+1)^{th}$ delta-encoded packet. The latter is required since after removing packet $P_{k}$, the compressed $(k+1)^{th}$ packet is encoded with respect to packet $P_{k-1}$. The two operations must be performed atomically to prevent inconsistent reading or decompression.

In order to perform the two operations above atomically, we assume that there is a software layer that triggers the removal operation, and that the removal itself is performed by the packet generation engine. When the software layer triggers the operation, it also provides $k$, the index of the packet to be removed, and $P^{\prime}_{k+1}$, the newly compressed $(k+1)^{th}$ packet.

Once the packet generation engine receives the removal request it:

Performs the conventional read-decompress-write procedure until it reaches packet $P_{k-1}$. 2. 2.

Reads and decompresses packets $P_{k}$ and $P_{k+1}$, but does not write them back to the memory. 3. 3.

Writes the newly compressed packet, $P^{\prime}_{k+1}$ immediately after packet $P_{k-1}$. 4. 4.

Continues the read-decompress-write procedure on packets $P_{k+2},\ldots,P_{N}$, so that each packet is written after the previously written packet, thus eliminating the gap created by removing $P_{k}$.

Insertion

Assume we have $N$ packet in the memory, and we want to insert a new compressed packet, $P$, before packet $P_{k}$. As in the removal procedure, two operations need to occur atomically: (i) inserting packet $P$, and (ii) updating packet $P_{k}$ to a newly encoded $P^{\prime}_{k}$. Again, we assume that there is a software layer that provides the location $k$, the packet that needs to be inserted $P$, and the newly encoded $P^{\prime}_{k}$.

Upon receiving an insertion request, the packet generation engine:

Performs the conventional read-decompress-write procedure until it reaches packet $P_{k-1}$. 2. 2.

Reads and decompresses packet $P_{k}$, but does not write it back to the memory. 3. 3.

Writes the newly inserted (compressed) packet $P$ immediately after $P_{k-1}$. 4. 4.

For packets $P_{k+1},\ldots,P_{N}$, the engine proceeds by reading packet $P_{j}$, decompressing it, and then writing packet $P_{j-1}$ after the previously written packet.

Note that in steps 2-4 above, the packet generation engine takes care not to write over packets that have not yet been read. For example, if the compressed packet $P_{j}$ is slightly shorter than $P_{j-1}$, the engine writes $P_{j-1}$ only after having read $P_{j+1}$. Thus, the packet generation engine maintains a small cache that stores the currently read packets.

II-D Random Access to FM Packets

In our approach we assumed that the FM packet memory is always accessed sequentially. However, in some cases the FM application may require an urgent packet $P_{k}$ to be sent immediately. The delta encoding scheme implies that in order to access the $k^{th}$ packet the packet generation engine must sequentially read all the preceding packets.

In order to allow quick random access, our delta encoding scheme can be extended to include entry points. For example, the FM software layer can store packets $P_{10},P_{20},P_{30},\ldots$ in uncompressed form. Thus, when the software layer instructs the packet generation engine to access the $21^{st}$ packet, it also provides the uncompressed $P_{20}$, and the engine can use $P_{21}$ with one memory access. In this example every packet in the FM memory can be reached in at most $9$ memory access operations.

III Evaluation

III-A Data Set

We evaluated our FM-Delta compression system on 100 sets of synthetically generated packets.333We did not use publicly available packet traces since these traces either do not include FM packets, or do not include packet payloads, thus preventing effective data compression analysis. Each set comprises 100k packets. Our synthesized data sets are publicly available [18].

The data sets consists of two types of packets: Continuity Check Messages (CCM) [5], and Bidirectional Forwarding Detection (BFD) [6] control messages. Each packet type was used on half of the data set. CCMs are defined over Ethernet, while BFDs are over IPv4-over-Ethernet. Each packet included a random number of VLAN tags (either 0, 1, or 2 tags).

The network topology can significantly affect the extent to which FM packets can be compressed in our setting. For example, if multiple FM packets are sent to the same destination device, then some of the packet fields may be similar in these packets. Moreover, in CCMs [5] the MEG ID field is a 48-byte field that has a different value in each Maintenance Entity Group (MEG) [5]. Thus, the number of devices per MEG can significantly affect the similarity among packets.

We assumed that the current device has a set of 32 MAC addresses, and thus the source MAC address of each packet was randomly chosen from the pool of 32 addresses, while the destination MAC address was randomly chosen444Throughout this section the ‘randomly chosen’ refers to a uniformly distributed selection. without constraints. The IP addresses of each BFD packet were randomly chosen. The VLAN IDs of each packet that included a VLAN tag was also randomly chosen. The MEG ID field in CCM packets was randomly chosen for each set of 3 CCM packets.555We assumed that the number of Maintenance Points (MP) [5] per Maintenance Entity Group (MEG) [5] is 4 on average.

Our experiments were performed in two modes: ordered mode, in which packets were arranged so as to allow a higher compression ratio, and random mode, in which packets were ordered randomly. In the ordered mode, the arrangement was implemented according to two criteria: (i) packets were ordered according to their size, allowing alignment between the fields of consecutive packets, and (ii) packets from the same MEG were grouped together.

III-B Results

We present a glimpse at some of our experimental results. Fig. 6(a) illustrates the compression ratio666The compression ratio is the ratio between the uncompressed data set and the compressed data set. using zlib. Since zlib supports nine possible compression levels, the graph presents the compression ratio for each of the levels.

Fig. 6(b) presents the compression ratio of the delta encoding algorithm as a function of the word size. The word size is a design parameter of the FM-Delta algorithm. Specifically, for the FM protocols that were analyzed in this work, if the word size is fixed at 2 bytes, we expect the algorithm to provide the best performance for the FM protocols we analyzed.

Notably, although the delta encoding algorithm is significantly simpler, it provides a comparable compression ratio; zlib provides a compression ratio of 2.9 at the highest compression level, but is not hardware-friendly, while the hardware-friendly FM-Delta provides a ratio of 2.6.

Another significant result is that the ordered message set allows a higher compression ratio, emphasizing the advantage of optimizing the order of the data set. Such an optimization is feasible in light of the relative flexibility of FM specifications as to the order and exact timing of packet transmission.

IV Conclusion and Outlook

In this paper we have shown that packet compression can significantly reduce the required on-chip memory in Fault Management protocol implementations. Surprisingly, delta encoding, which is typically dismissed as an ineffective compression approach, is shown to be highly effective for packet compression. We introduce a simple and hardware-friendly delta encoding algorithm that provides a compression ratio of 2.6, and allows to reduce the cost of packet processor silicons.

Potential improvements of FM-Delta can be considered, for example by using a dictionary for common field values. Furthermore, the preliminary results presented in this paper can be further established by experimenting with a hardware implementation of FM-Delta, and by analyzing real-life traces of FM messages. Notably, the concepts we presented may be applied not only to FM messages, but also to other types of control messages that are stored by switches and routers.