Network Coding for Critical Infrastructure Networks

The applications in the critical infrastructure systems pose simultaneous resilience and performance requirements to the underlying computer network. To meet such requirements, the networks that use the store-and-forward paradigm poses stringent conditions on the redundancy in the network topology and results in problems that becoming computationally challenging to solve at scale. However, with the advent of programmable data-planes, it is now possible to use linear network coding (NC) at the intermediate network nodes (i.e. hardware and software switches) to meet resilience requirements of the applications. To that end, we propose an architecture that realizes linear NC in programmable networks by decomposing the linear NC functions into the atomic coding primitives. We designed and implemented the primitives using the features offered by the P4 ecosystem. Using an empirical evaluation of an open-source prototype, we show that the theoretical gains promised by linear network coding can be realized with a per-packet processing cost.



page 1

page 2

page 3

page 4


Random Linear Network Coding on Programmable Switches

By extending the traditional store-and-forward mechanism, network coding...

Isolation mechanisms for high-speed packet-processing pipelines

Data-plane programmability is now mainstream, both in the form of progra...

Evaluating Blockchain Application Requirements and their Satisfaction in Hyperledger Fabric

Blockchain applications may offer better fault-tolerance, integrity, tra...

TurboKV: Scaling Up The Performance of Distributed Key-Value Stores With In-Switch Coordination

The power and flexibility of software-defined networks lead to a program...

Gauntlet: Finding Bugs in Compilers for Programmable Packet Processing

Programmable packet-processing devices such as programmable switches and...

The Socket Store: An App Model for the Application-Network Interaction

A developer of mobile or desktop applications is responsible for impleme...

Multi-destination Aggregation with Binary Symmetric Broadcast Channel Based Coding in 802.11 WLANs

In this paper we consider the potential benefits of adopting a binary sy...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The applications that constitute the critical infrastructure (e.g. smart power generation and distribution systems, oil refineries etc.) have a unique set of requirements regarding their underlying communication networks. For example, such applications require that their communication is seamlessly resilient against link or device failures. Furthermore, these applications also require a predictable end-to-end delay for data delivery in multicast settings [1] [2]. Such resilience and performance requirements cannot be simultaneously accomplished by mere over-provisioning of network resources such as topological redundancy or bandwidth.

Rather, in the packet store-and-forward paradigm, the resiliency is provided by carefully routing the packets around a failed link or network device [3] [4] [5] [6]. However, such an approach requires solving complex combinatorial problems. Similarly, performance requirements (e.g. end-to-end delay) are met by solving resource allocation problems on a per-flow basis [7], but even a static resource allocation for flows that have such performance requirements is an NP-complete problem [8]. Therefore, combining the performance and resilience requirements poses an intractable problem.

Such intractability is a result of hard routing and resource allocation decisions that are in turn a consequence of the atomic nature of a packet flow in the store-and-forward paradigm. In this paradigm, a flow has to originate at a source port and follow a specific path to arrive at the destination(s) without any modifications to its contents. However, network coding converts this hard decision into one of many soft decisions by mixing packets at intermediate network devices using algebraic coding. In theory, NC promises to provide seamless resilience to failures for critical infrastructure applications over the store-and-forward paradigm [9] [10]. However, practical NC that achieves the promised theoretical gains has remained elusive.

Clearly, NC is realized when the intermediate network devices can be programmed to implement the packet coding and decoding capabilities. While there have been successful attempts to demonstrate the efficacy of using inter-session NC in wireless networks [11] [12], the progress on the widespread adoption of the same has been disappointing. In part, the reason has been the practical issues of retrofitting NC onto the prevalent networking architecture. These issues have been addressed in various ingenious efforts in the past [13] [14]. But, more importantly, the adoption of NC has been stifled due to a lack of programmable platforms that can implement novel data-plane methods at scale. Historically, the switch ASIC architectures that implement data-plane functionality have been optimized for ever-increasing line-speed performance at the expense of programmability. However, very recently, with the advent of programmable data-planes [15], it has become possible to not only experiment [16], but also deploy new network functions using a flexible data-plane architecture in production networks [17].

Based on these developments, we devise an architecture capable of simultaneously meeting resilience and performance requirements of the data streams generated by applications in critical infrastructure systems. To that end, we present one that leverages programmable networks to replace routing algorithms with NC functions. Our contributions include:

  • A library of atomic network coding primitives implemented using the programmable data-planes.

  • Use of the proposed primitives to construct linear network coding functions capable of achieving specific requirements for applications’ data streams.

  • Evaluation of the coding functions to show that the seamless resilience and multicast rate gains are obtained at a small per-packet processing cost of coding and decoding the packets in the data-plane.

The remainder of this paper is organized as follows: Section II discusses related work; Section III discusses background and how the features of programmable data-planes affect the design of coding functions and primitives; Section IV proposes an architecture to implement coding functions; Section V discusses the design of various elements of the proposed architecture; Section VI evaluates the performance and costs of using the proposed design; and Section VII concludes and discusses future work.

Ii Related Work

There has been prior work in the store and forward paradigm that allows nearly instantaneous failure recovery. When such failures are addressed reactively, they result in prohibitively large restoration time for critical infrastructure applications [18] [1]. There are proactive approaches to deal with such failures which use the mechanisms local to a switch to reroute traffic on an alternative path [3] [4] [5] [6]. However, such approaches require -connected network topologies for sustaining link failures, thus incurring a large overhead in procuring and maintaining such networks. Furthermore, these approaches require solving combinatorial problems to choose alternative links in the event of link failures. These approaches also lead to new problems such as the need to ”load-balance” resilience so that a small set of links does not become too critical for the resulting network after the failures.

Recently, in order to meet the performance guarantees in store-and-forward networks, the standard bodies have proposed standards for special-purpose hardware [19] [20]. However, using such special hardware incurs large capital and recurring expenses. To that end, some recent work has proposed mechanisms to simultaneously meet per-flow end-to-end delay and bandwidth requirements using software-defined commodity networks [7]

. However, this work solves a resource allocation problem using a heuristic for a multi-constraint path problem that provides no guarantees of optimality.

The seminal work that demonstrated a practical mechanism to implement NC by using simulations was done by Chou et. al. [14]. This work focused on coding batches of data which is incompatible with the acknowledgement mechanisms of TCP. Subsequently, there has been work that demonstrated TCP throughput gains with the use of NC [13] [21] with deployable implementations. However, these efforts focus on intra-session coding at source only and the goodput gains obtained due to intermittent packet loss.

There have been several prior efforts to implement NC top of on the application layer, either in an overlay topology [22] [23] [24] or as a virtual network function [25]. While implementing NC in the application layer offers flexibility and variety in the type applications that can be materialized, the cost of taking packets from the network interface and processing them in upper layers can be high and can be mitigated by implementing NC in the data-plane of network devices.

Finally, COPE [11] demonstrated the benefits of inter-session coding in the specific setting of wireless networks by utilizing the broadcast property of the media with a clever heuristic. The types of benefits that COPE extracted using a specially designed architecture can now be replicated for wired networks by implementing NC using standard platforms such as the P4 ecosystem.

Iii Motivation and Background

Iii-a Why use Network Coding?

In the store-and-forward paradigm, each flow originates at a source port and follows a deterministic path to arrive at the destination port(s), however, its contents are immutable during the transit. Hence, due to immutability, when globally optimal decisions for resource allocation for flows are to be made, the resources are allocated separately for each flow at the network devices. Furthermore, in the event of a link or device failure, the flows must be routed around the failure entirely. Due to these requirements of immutability, solving for performance guarantees and resilience requirements results in formulation of problems that are intractable [8] [7] or combinatorially complex [3] [4] [5] [6].

The NC paradigm approaches the problem of delivering data from point A to point B by allowing intermediate nodes within the network to code and recode the packets. This paradigm has many promising theoretical properties. For example, in their seminal work, Ahlswede et. al. [9] showed that, given a network represented as a multigraph , network coding can enable a sender to communicate with a set of receivers , at a multicast rate equal to the minimum max-flow from the sender to any of the . Li et. al. [26] showed that using linear codes on the network nodes are sufficient to achieve this rate. Koetter and Medard [10] extended the theorem to the cases when the edges in are subject to failures and showed that the linear codes can achieve minimum max-flow even after failures. Finally, Ho et. al. [27] showed that the random linear network codes suffice to achieve the same.

Iii-B Why use the P4 ecosystem?

The implementation of linear NC requires two types of computations: First, there are network-level operations such as computation of coding co-efficients or designation of various roles to the individual nodes based on the topology and the application requirements. These operations can be performed in the programmable control-plane. Second, there is the simple arithmetic operations (e.g. addition, multiplication) that are performed on an individual or a small batch of packets in the applications’ data stream. In order for coding to scale to line-speeds, these operations have to be performed on the individual network devices using a programmable data-plane architecture.

The P4 ecosystem is a programmable data-plane architecture has been gaining traction in both academia and industry for implementing novel data-plane functions. It comprises an open-source language [15] [28] and the accompanying Portable Switch Architecture (PSA) [29]. The ecosystem has accelerated the design and adoption of novel network functions by enabling fully programmable data-planes without compromising the line-speed performance of modern network devices.

The primary goal of the P4 ecosystem is to make data-planes programmable by allowing expression of per-packet computations performed on a network device. As such, it is not designed to enable network coding applications. However, it does provide several features that make it well-suited as a platform for implementing linear NC functions for failure resilience and multicast rate enhancements. Below, we briefly describe some of the relevant features:

  • Customizable Packet Processing Pipelines: There are separate ingress and egress pipelines on each PSA device which can be configured from the control-plane. These pipelines are constructed using tables. Each table has a set of fields (called its key) that determines the packets that match it. Each table also has associated C-link sub-routines called actions. The actions can perform nearly arbitrary operations on the packet headers including for example addition, multiplication and XOR.

  • Packet Cloning & Recirculation: Cloning makes copies of packets on the egress pipeline, while recirculation sends the packets from the egress pipeline to the ingress pipeline. Both of these features can be used in tandem to generate a new packet for coding/decoding operations. Furthermore, since P4 does not have a primitive analogous to a loop in imperative programming languages, packet cloning and recirculation can also be used to create one without any intervention from end-hosts.

  • Registers: Registers are essentially global variables that can hold global state independent of any specific packet in any given pipeline. These registers can be used to drive state machines and implement data structures that hold packets that are required to be coded.

  • Extensibility: P4 allows extension of the core language by using a construct called extern. Essentially, this construct allows another level of flexibility to implement features that do not exist in the language. Such flexibility may be crucial to any implementation of NC that goes beyond simple linear codes.

Iv Architecture

Fig. 1: Architecture

The Figure 1 illustrates the proposed architecture which enables implementation of linear network coding using P4 devices. This particular example shows a steam of packets carrying applications’ data originates at the host on the left side and terminates on the host at the right side. Fundamentally, we assume that a packet stream can be divided into a batches of packets. These batches are then processed by individual devices to achieve the NC gains.

We define a coding function as the realization of a linear code to improve resilience or throughput of a unicast/multicast data stream. For example, in Figure 1, the function implements a diversity code [30] to provide resilience to failure of any one of the three paths between and . The function replaces IP forwarding and spans one or more P4 enabled devices. A northbound coding application implements multiple coding functions that operate simultaneously across the network.

A coding primitive is an atomic block of functionality implemented on the individual P4 switches. For example, in Figure 1, switches and implement the coding and decoding primitives respectively. Each primitive operates independently of the others. Each incident stream of packets on the device is subject to one or more primitives. A switch can process multiple data streams simultaneously. Each switch’s configuration contains the identifier for the data streams and the exact sequence of coding primitives applied to each of them.

V Design

In this section, we first describe our design for the coding functions in the control-plane. Next, we discuss the packet header that is used to coordinate primitives for a given coding function and finally describe how our design of the coding primitives in the data-plane using the P4 ecosystem.

Fig. 2: Network Coding Primitives



Fig. 3: Linear Coding Functions: (a) For multicast rate improvements over a butterfly topology (b) For seamless failure resilience to failure of links in any one of three available paths

V-a Coding Functions

The coding functions are a part of the coding application. Each coding function takes as input the source host and destination host(s) associated with the data stream. It accesses the topology information by using the controller’s northbound API. Then, the coding function generates the configuration for the coding primitives described later in this section. Figure 3 shows two instances of coding functions. One instance is that of a diversity code that provides seamless resilience for a unicast stream over three paths. The other instance uses a linear code for enhancing receiver’s data rate of a multicast stream.

V-B Coding Header

Each packet that belongs to a coding function carries a coding header. The header contains various fields to coordinate the operations performed by the coding primitives across the network. The header has a field called next_primitive which determines what happens to the packet when it arrives at a network device. It also has a field called stream_id to identify packets belonging to different streams. Finally, it has the batch_number which identifies the packets belonging to a given batch of packets within the stream.

Since P4 does not provide access to the contents of a packet beyond a few hundred bytes, in our prototype, we use a field in the coding header to carry the packet’s payload.

V-C Coding Primitives

The coding primitives are implemented in the data-plane on the individual network devices using P4. The primitives are implemented primarily in the ingress pipeline. However, some of the primitives use the egress pipeline for recirculating cloned packets for generating new packets that carry coded/decoded payload. For every primitive, we also collect some in-band telemetry to measure processing times for evaluation.

Coding primitives use several common design patterns. Each primitive uses at least one table in the ingress pipeline. If the primitive uses packet cloning and recirculation, then it also uses a table in the egress pipeline. Furthermore, each primitive table has a common field called stream_id as part its key. This field is used to specify the packets belonging to an specific application’s data stream. These packets could originate at the host or could be the result of the output of another primitive.

Each table implements a decision tree. The levels of the tree are determined by values taken by the fields in the

key of the table. The actions in the table form the leaves in the decision tree. These actions either perform the mathematical operation for coding/decoding packets or manipulate some global state that is held in registers.

Next, we describe the particulars of the individual primitives. As illustrated in the Figure 2, we developed five primitives to implement linear inter-session NC as follows:

  • Splitting: primitive splits a given packet stream arriving from a single interface into individual batches of packets. It uses global state in registers on a per stream basis and stores the packets in the appropriate registers so that the coding/decoding primitives can use them.

  • Coding: primitive generates new packets whose payload are obtained by coding over the previously stored payloads. It accomplishes that by using the cloning and recirculation features to create a loop to generate packets whose payload is then populated to be the coded packets. In order implement linear codes, the coding primitive only performs addition, subtraction and XOR operations provided by P4.

  • Forwarding: primitive performs unicast or multicast forwarding of a packet. The multicast forwarding action makes use of cloning to generate copies of packets.

  • Gathering: primitive collects a batch of incoming packets from multiple interfaces and puts them into the registers corresponding to their stream_id. It also relies on global state in registers to keep track of the packets it has received on a per-stream basis.

  • Decoding: primitive takes the gathered packets, decodes them and forwards the payload packets to the host. In order to generate decoded payload, this operation may also require generating new packets. This primitive also uses cloning and recirculation to generate new packets that are then populated with decoded payload.

Clearly, the coding and decoding primitives require buffering of the packets. In our current prototype, we use the registers to maintain a fixed size ring buffer containing the packet payloads and use the batch_number to locate them appropriately. The packets belonging to same stream of packets are correlated by using the stream_id. In our design, we do not perform any flow control on the switches.

Vi Evaluation

We implemented a prototype of the library of primitives and functions that use them. Our prototype is available in the public domain [31]. We evaluated our approach using mininet [32] and a software switch [33] as P4 target. The end-host were emulated using python scripts that used scapy [34] to construct and parse custom coding headers. The emulations were performed on a machine that was running Ubuntu 16.04 LTS. The machine had eight processor cores clocked at 2.7 GHz and 16 GB of RAM. We performed two types of evaluation that are described below.

Fig. 4: Processing time per packet for coding and decoding using the diversity code

Vi-a Multicast Rate Gains of Coding

We performed an experiment to measure the multicast rate gains that are obtained when using a simple linear code to perform multicast over the classic butterfly network shown in Figure 3(a). The host on the left side wants to multicast a data stream to the two hosts on the right. Suppose the bandwidth of the links between the switches is bps. Theoretically, coding should allow a multicast rate of bps for flows and simultaneously, whereas any scheme that uses packet forwarding would not be able to accomplish this rate because only a single packet can be forwarded along the link .

We sent a thousand packets at various data send rates with an exponentially distributed inter-packet time to match the rate. Each packet contained 4096 bytes of payload. The

was set to Mbps. We measured the simultaneous received data rate on each receiver by using the packet payload sizes and their timestamps in the generated PCAP files to obtain the range of time for which the transmission was received at each receiver,

Figure 5 plots two ratios. The x-axis is the ratio of send-rate over the max-flow between the source and destination host, whereas the y-axis is the ratio of observed received rate at one of the receiving hosts (without loss of generality and empirically identical) over the send rate. We observed that the received rate drops for forwarding as the send rate is about 40% of the max-flow, whereas it does not drop for coding until 80% of the max-flow. At 80%, we see a drop for coding as well, likely because the processing delays associated with coding at nodes , , .

Fig. 5: Comparison between received rate achieved using coding vs forwarding in the butterfly topology

Vi-B Microbenchmarks

We performed an experiment to measure the processing time associated with coding and decoding packets in a P4-enabled switch. We used in-band telemetry to measure the processing time at each switch in the path of the packet. The processing time is measured as difference between the time-stamp associated with packet arriving at the ingress pipeline and packet being queued for egress.

We used the framework described above to implement diversity coding over multiple alternative paths as shown in Figure 3(b). Each link was set to have a delay of 5 ms. The delay for link between - was varied to create a delay differential for packets arriving at for decoding. Furthermore, we measured the impact of payload size on the processing time as well. We sent a thousand packets for a each point in the plot shown in Figure 4. The packets were sent as fast as possible (i.e. there was no sleep between any two packets).

We observed a negligible effect of increasing the payload sizes of packets for all operations. Specifically, we observed that the processing time for the set of switches that forward the packets (i.e. , , ) increases only slightly even when payload sizes are quadrupled. In the worst case, we observe that processing time at the coding node (i.e. ) can be up to four times the processing time for only forwarding the packets. Similarly, in the worst-case, decoding node (i.e. ) can take up to six times to process a packet than a forwarding node. Some of this variation and extra processing time is due to the cloning and recirculation operation that coding and decoding primitives use.

Finally, we observe that for a lower link delay differential, the decoding time is higher than coding time and has a high standard deviation and vice versa. This is because different set of table actions are in effect in those two cases. For a lower link delay differential, the XOR packet arrives at the decoder first and necessitates the use of arithmetic decoding, whereas when the differential is higher, the decoding is essentially reduced to forwarding the uncoded packets.

Vii Conclusion and Future Work

We proposed an architecture that realizes linear NC in programmable networks by decomposing the linear NC functions into the atomic coding primitives. In our future work, we want to verify whether the gains associated with NC are also observed in hardware devices. Furthermore, we want to study the resilience and throughput gains for more complex coding functions and in larger topologies. Finally, we also want to study how NC can be used to control the trade-offs between network resources, the level of resilience and end-to-end delay.


  • [1] D. E. Bakken, A. Bose, C. H. Hauser, D. E. Whitehead, and G. C. Zweigle, “Smart generation and transmission with coherent, real-time data,” Proceedings of the IEEE, vol. 99, no. 6, pp. 928–951, 2011.
  • [2] K. Leggett, R. Moxley, and D. Dolezilek, “Station device and network communications performance during system stress conditions,” in proceedings of the Protection, Automation and Control World Conference, Dublin, Ireland, 2010.
  • [3] T. Elhourani, A. Gopalan, and S. Ramasubramanian, “Ip fast rerouting for multi-link failures,” IEEE/ACM Transactions on Networking, vol. 24, no. 5, pp. 3014–3025, 2016.
  • [4] Y.-A. Pignolet, S. Schmid, and G. Tredan, “Load-optimal local fast rerouting for resilient networks,” in Dependable Systems and Networks (DSN), 2017 47th Annual IEEE/IFIP International Conference on.   IEEE, 2017, pp. 345–356.
  • [5] M. Chiesa, I. Nikolaevskiy, S. Mitrović, A. Panda, A. Gurtov, A. Maidry, M. Schapira, and S. Shenker, “The quest for resilient (static) forwarding tables,” in Computer Communications, IEEE INFOCOM 2016-The 35th Annual IEEE International Conference on.   Ieee, 2016, pp. 1–9.
  • [6] M. Chiesa, A. Gurtov, A. Madry, S. Mitrovic, I. Nikolaevskiy, M. Shapira, and S. Shenker, “On the resiliency of randomized routing against multiple edge failures,” in LIPIcs-Leibniz International Proceedings in Informatics, vol. 55.   Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2016.
  • [7] R. Kumar, M. Hasan, S. Padhy, K. Evchenko, L. Piramanayagam, S. Mohan, and R. B. Bobba, “End-to-end network delay guarantees for real-time systems using sdn,” in IEEE Conference Real-Time Systems Symposium (RTSS)(Accepted), 2017.
  • [8] Z. Wang and J. Crowcroft, “Quality-of-service routing for supporting multimedia applications,” IEEE Journal on selected areas in communications, vol. 14, no. 7, pp. 1228–1234, 1996.
  • [9] R. Ahlswede, N. Cai, S.-Y. Li, and R. W. Yeung, “Network information flow,” IEEE Transactions on information theory, vol. 46, no. 4, pp. 1204–1216, 2000.
  • [10] R. Koetter and M. Médard, “An algebraic approach to network coding,” IEEE/ACM Transactions on Networking (TON), vol. 11, no. 5, pp. 782–795, 2003.
  • [11] S. Katti, H. Rahul, W. Hu, D. Katabi, M. Médard, and J. Crowcroft, “Xors in the air: practical wireless network coding,” IEEE/ACM Transactions on Networking (ToN), vol. 16, no. 3, pp. 497–510, 2008.
  • [12] P. Ostovari, J. Wu, and A. Khreishah, “Network coding techniques for wireless and sensor networks,” in The Art of Wireless Sensor Networks.   Springer, 2014, pp. 129–162.
  • [13] J. K. Sundararajan, D. Shah, M. Médard, M. Mitzenmacher, and J. Barros, “Network coding meets tcp,” in INFOCOM 2009, IEEE.   IEEE, 2009, pp. 280–288.
  • [14] P. A. Chou, Y. Wu, and K. Jain, “Practical network coding,” in Proceedings of the annual Allerton conference on communication control and computing, vol. 41, no. 1.   The University; 1998, 2003, pp. 40–49.
  • [15] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford, C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese et al., “P4: Programming protocol-independent packet processors,” ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, pp. 87–95, 2014.
  • [16] H. Wang, R. Soulé, H. T. Dang, K. S. Lee, V. Shrivastav, N. Foster, and H. Weatherspoon, “P4fpga: A rapid prototyping framework for p4,” in Proceedings of the Symposium on SDN Research.   ACM, 2017, pp. 122–135.
  • [17] “Barefoot Networks: Tofino,”, 2018, [Online; accessed March-2018].
  • [18] N. L. Van Adrichem, B. J. Van Asten, and F. A. Kuipers, “Fast recovery in software-defined networks,” in Software Defined Networks (EWSDN), 2014 Third European Workshop on.   IEEE, 2014, pp. 61–66.
  • [19] “Ieee standard for local and metropolitan area networks – bridges and bridged networks – amendment 26: Frame preemption,” IEEE Std 802.1Qbu-2016 (Amendment to IEEE Std 802.1Q-2014), pp. 1–52, Aug 2016.
  • [20] M. D. J. Teener, A. N. Fredette, C. Boiger, P. Klein, C. Gunther, D. Olsen, and K. Stanton, “Heterogeneous networks for audio and video: Using ieee 802.1 audio video bridging,” Proceedings of the IEEE, vol. 101, no. 11, pp. 2339–2354, 2013.
  • [21] J. Krigslund, J. Hansen, D. E. Lucani, F. H. Fitzek, and M. Médard, “Network coded software defined networking: Design and implementation,” in European Wireless 2015; 21th European Wireless Conference; Proceedings of.   VDE, 2015, pp. 1–6.
  • [22] C. Gkantsidis, J. Miller, and P. Rodriguez, “Comprehensive view of a live network coding p2p system,” in Proceedings of the 6th ACM SIGCOMM conference on Internet measurement.   ACM, 2006, pp. 177–188.
  • [23] C. Gkantsidis and P. R. Rodriguez, “Network coding for large scale content distribution,” in INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE, vol. 4.   IEEE, 2005, pp. 2235–2245.
  • [24] C. Wu, B. Li, and Z. Li, “Dynamic bandwidth auctions in multioverlay p2p streaming with network coding,” IEEE Transactions on Parallel and Distributed Systems, vol. 19, no. 6, pp. 806–820, 2008.
  • [25] L. Zhang, S. Lai, C. Wu, Z. Li, and C. Guo, “Virtualized network coding functions on the internet,” in Distributed Computing Systems (ICDCS), 2017 IEEE 37th International Conference on.   IEEE, 2017, pp. 129–139.
  • [26] S.-Y. Li, R. W. Yeung, and N. Cai, “Linear network coding,” IEEE transactions on information theory, vol. 49, no. 2, pp. 371–381, 2003.
  • [27] T. Ho, M. Médard, R. Koetter, D. R. Karger, M. Effros, J. Shi, and B. Leong, “A random linear network coding approach to multicast,” IEEE Transactions on Information Theory, vol. 52, no. 10, pp. 4413–4430, 2006.
  • [28] “P4: Language Specification,”, 2018, [Online; accessed March-2018].
  • [29] “P4: Portable Switch Architecture Specification,”, 2018, [Online; accessed March-2018].
  • [30] E. Ayanoglu, I. Chih-Lin, R. D. Gitlin, and J. E. Mazo, “Diversity coding for transparent self-healing and fault-tolerant communication networks,” IEEE Transactions on communications, vol. 41, no. 11, pp. 1677–1686, 1993.
  • [31] “Open Source Implementation,”, 2018, [Online; accessed March-2018].
  • [32] B. Lantz, B. Heller, and N. McKeown, “A network in a laptop: rapid prototyping for software-defined networks,” in Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks.   ACM, 2010, p. 19.
  • [33] “Behavioral Model Repository,”, 2018, [Online; accessed March-2018].
  • [34] “Scapy: the Python-based interactive packet manipulation program and library,”, 2018, [Online; accessed March-2018].