|
1 | | -# A library for Network Decision Diagram |
| 1 | +# A library for Network Decision Diagram (NDD) |
2 | 2 |
|
3 | | -This is a prototype implementation of the following [paper](https://xjtu-netverify.github.io/papers/NDD/NDD-final-version.pdf): |
| 3 | +This is an implementation of the following [paper](https://xjtu-netverify.github.io/papers/NDD/NDD-final-version.pdf): |
4 | 4 |
|
5 | 5 | > Zechun Li, Peng Zhang, Yichi Zhang, and Hongkun Yang. "NDD: A Decision Diagram for Network Verification", NSDI 2025 |
6 | 6 |
|
7 | 7 | ## Introduction |
8 | 8 |
|
9 | | -**Network Decision Diagram (NDD)** is a new decision diagram customized for network verification. It is more efficient than BDD when used for network verification, in terms of memory and computation. NDD wraps BDD with another layers of decision diagram, such that each node represents a **field** of the network, and each edge is labeled with a BDD encoding the values of that field. Due to the **locality** of fields in networks, NDD can significantly reduce the redundant nodes. |
| 9 | +**Network Decision Diagram (NDD)** is a new decision diagram based on the classical Binary Decision Diagram (BDD). |
| 10 | +In BDD, each node looks at a single **bit**, and branches based on whether the bit is true or false; |
| 11 | +while in NDD, each node looks at a **field** which either bears some semantics meaning, say an IP address, or simply a fixed number of bits. |
| 12 | +Since the node may have more than 2 branches, we represent the branching condition with external data structures. |
| 13 | +Current, NDD uses BDD to represent the branching condition: if the field has $n$ bits, then the condition for each branch is a BDD with $n$ variables. |
| 14 | +In this sense, NDD can be seen as wrapping the original BDD with another layer of decision diagram, and therefore can also be interpreted as "Nested Decision Diagram". |
10 | 15 |
|
11 | | -As an example, the figure below shows three BDDs in (a), and three equivalent NDDs in (c), each edge of which is labelled by per-field BDDs in (b). |
| 16 | +## Benchmark |
| 17 | + |
| 18 | +Benchmark (time `second`) on **NQueens** |
| 19 | + |
| 20 | +| N | BDD (JDD) | BDD (JavaBDD - JFactory) | NDD (JNDD) | |
| 21 | +| - | --------- | ------------- | -------------------- | |
| 22 | +| 6 | 0.017 | 0.056 | 0.012 | |
| 23 | +| 7 | 0.023 | 0.072 | 0.019 | |
| 24 | +| 8 | 0.04 | 0.109 | 0.038 | |
| 25 | +| 9 | 0.223 | 0.28 | 0.176 | |
| 26 | +| 10 | 0.615 | 0.913 | 0.344 | |
| 27 | +| 11 | 2.567 | 4.424 | 2.257 | |
| 28 | +| 12 | 19.109 | 33.024 | 12.417 | |
| 29 | + |
| 30 | +More benchmarks will be available soon. |
| 31 | + |
| 32 | +## The Origin of NDD |
| 33 | + |
| 34 | +NDD was originally proposed for network verification, where each NDD node represents a packet header field (destination IP address) |
| 35 | +We observed NDD was more efficient than BDD in terms of memory and computation. |
| 36 | +The reason is due to the **locality** of field-based matching semantics, NDD can significantly reduce the number of BDD nodes for each field. |
| 37 | +The figure below shows an example, where the three BDDs in (a) can be represented by three equivalent NDDs in (c), |
| 38 | +where each edge of which is labelled by per-field BDDs in (b). |
12 | 39 |
|
13 | 40 |  |
14 | 41 |
|
| 42 | +<!-- |
15 | 43 | **Atomized Network Decision Diagram (Atomized NDD)** is an extension of NDD, which offers a native support for equivalence classes, a key technique underlying most network verifiers. |
16 | 44 | In atomized NDD, the label of each edge is a set of atoms, instead of a BDD as in standard NDD. |
17 | 45 | Using atomized NDD, network verifiers do not need to implement their own algorithms for computing and updating equivalence classes. |
18 | 46 |
|
19 | | -<!-- |
| 47 | +
|
20 | 48 | ### Definitions |
21 | 49 |
|
22 | 50 | **Definition 1.** A **Network Decision Diagram (NDD)** is a rooted, directed acyclic graph with: |
@@ -197,19 +225,7 @@ The `triggered by` field indicates whether the NDD GC was: |
197 | 225 | - `JDD prehook`: Called automatically before JDD GC to ensure NDD nodes are cleaned up first |
198 | 226 | - `NDD self`: Triggered by NDD's own table size limit |
199 | 227 |
|
200 | | -## Benchmark |
201 | | - |
202 | | -Benchmark (time `second`) on **NQueens** |
203 | 228 |
|
204 | | -| N | BDD (JDD) | BDD (JavaBDD - JFactory) | NDD (JNDD) | |
205 | | -| - | --------- | ------------- | -------------------- | |
206 | | -| 6 | 0.017 | 0.056 | 0.012 | |
207 | | -| 7 | 0.023 | 0.072 | 0.019 | |
208 | | -| 8 | 0.04 | 0.109 | 0.038 | |
209 | | -| 9 | 0.223 | 0.28 | 0.176 | |
210 | | -| 10 | 0.615 | 0.913 | 0.344 | |
211 | | -| 11 | 2.567 | 4.424 | 2.257 | |
212 | | -| 12 | 19.109 | 33.024 | 12.417 | |
213 | 229 |
|
214 | 230 | ## Bibtex |
215 | 231 |
|
|
0 commit comments