Our approach is to eliminate bugs virtually (with use of virtualization technologies). We design a bug-tolerant router (BTR), which
masks buggy behavior, and avoids letting it affect correctness of the network layer.
This is achieved through running multiple, diverse, instances of router software in parallel. The main question then becomes how
is diversity achieved and how will it be deployed. First, to discuss the types of diversity that is possible:
- Implementation - running software from different code bases (e.g.,
Quagga,
XORP,
Bird).
- Version - running multiple versions the same code base (e.g., v0.98.6 and v0.99.11)
- Update order/timing - Change timing of update messages.
- Connection establishment order/timing - Changing the timing and order of connection establishment.
- Protocol - run different protocols in parallel that will each chose the same route.
- Execution environment - e.g., operating system, memory layout.
Different deployment scenarios are possible. An open source router vendor may run XORP, Quagga, and Bird together, which is sufficient.
A closed source vendor may have various development trains internally or software acquired from an acquisition, and make use of version
and data diversity. A network operator might run implementation diversity (using commercial router software), and protocol diversity, along
with version and open source software.